maria-developers team mailing list archive

[Jeremy Cole <jeremycole@xxxxxxxxxx>]

Sergei,


> > Additionally I would suggest a new sysvar to control the rounding
> > behavior of the same temporal types, e.g.
> > temporal_microsecond_rounding={round|truncate} which controls whether
> > to round (as Oracle MySQL 5.6 does) or to truncate (as MariaDB does)
> > when faced with fitting a larger number of decimals in a value into a
> > smaller number decimals in a field. (This of course assumes that the
> > current MariaDB behavior and divergence from Oracle MySQL behavior is
> > intentional, and not a bug. Even if it is considered a bug it could
> > probably not be changed outright at this point and the sysvar would
> > still be needed.)
>
> Perhaps, yes. When this feature was discussed in MySQL, while I was
> still there, we all were in agreement about truncating, not rounding.
> With the reasoning - to avoid drastic date changes, like, when a year
> changes when you store 1999-12-31 23:59:59.9999 in DATETIME(1) column.
>
> I don't know why Oracle has changed that and their arguments, we in
> MariaDB still thought that these drastic date changes would be an
> undesirable gotcha, and we've decided to truncate. So, not a bug.
>

I guess it doesn't matter why they decided to differ, but the fact that
they did means that something has to be done in MariaDB. For instance, if
replicating from MySQL 5.6 to MariaDB, the rounding differences will
potentially cause completely different values to be stored for the same
query, causing data drift between master and slave.

> Any thoughts on either of these? We would of course be willing to do
> > the work and provide the patches for them. I just wanted to get your
> > general feelings on the ideas.
>
> Bar made a point about sysvars being difficult for replication.
>
> I'd say, it depends on your use case. If it's important to run CREATE
> TABLE on the master and have a temporal column to be created on the
> slave using exactly the same binary on-disk format (especially, if one
> expects to change this sysvar often) - then sysvar changes must be
> replicated, and it would need special support from the replication code.
>
> Otherwise - if the above is not the goal - then sysvar is a good
> and clean approach, agree.
>

I think there are two cases here with different goals perhaps:


   1. The on-disk storage format