> 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 wasstill there, we all were in agreement about truncating, not rounding.With the reasoning - to avoid drastic date changes, like, when a yearchanges 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 inMariaDB still thought that these drastic date changes would be an
undesirable gotcha, and we've decided to truncate. So, not a bug.
> 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 CREATETABLE on the master and have a temporal column to be created on theslave using exactly the same binary on-disk format (especially, if oneexpects to change this sysvar often) - then sysvar changes must bereplicated, 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.