Hi, Seth! On Feb 21, Seth Shelnutt wrote:
To support TIMESTAMP WITH TIME ZONE and TIME WITH TIME ZONE literals (literals only, not expressions or fields or variables), it would be enough to parse them in str_to_datetime(), there is no need to return the time zone back to the caller in MY_TIME.
In adding a gmt_offset variable, and boolean flag to MY_TIME struct it will break abi compatibility. What are the standards around abi compatibility changes?
We change the ABI, we need to change the library version. That's a lot of work, old clients will need the old library, we'll maintain *-compat package with old library versions, etc.
Would adding all relevant changes behind #ifdef be sufficient? In that case, at compile time a user could choose to maintain existing abi compatibility, or choose to enable TIME(STAMP) with TIME ZONE literal support?
No, #ifdef in the ABI is a very bad idea. A user will never know whether the application will work or it'll crash. The library name and a version should always identify the ABI unambiguously. What do you want to achieve at the end? What's your use case? If it's *only* reading timestamps with a time zone, that is only literals for insert/update/etc - then you can do with a rather small fix, no ABI changes, no new data types, no on-disk format changes, nothing. A full support, a new data type TIMESTAMP WITH TIME ZONE - is significantly more complex, though. Regards, Sergei Chief Architect MariaDB and security@mariadb.org