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 secur...@mariadb.org _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
