maria-developers team mailing list archive

[Jeremy Cole <jeremycole@xxxxxxxxxx>]

Wow, I accidentally sent that (Command-Enter boo). Ignore that; real reply
coming shortly.


On Wed, Nov 13, 2013 at 9:39 AM, Jeremy Cole <jeremycole@xxxxxxxxxx> wrote:

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