maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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@xxxxxxxxxxx