← Back to team overview

maria-developers team mailing list archive

Re: new timestamp fields

 

Another question, are old timestamp fields stored the way is used to be? as
a little endian integer? or are those now big-endian as well?


On Tue, Jan 15, 2013 at 2:32 PM, Sergei Golubchik <serg@xxxxxxxxxxxx> wrote:

> Hi, Zardosht!
>
> On Jan 15, Zardosht Kasheff wrote:
> > Hello all,
> >
> > In MySQL/MariaDB 5.1, when a timestamp field was used as a key, we
> > used an integer compare to compare the fields. We assumed all integer
> > fields (including date, time, and timestamp) could use an integer
> > comparison to compare the fields, and that they were either 1, 2, 3, 4
> > or 8 bytes long.
> >
> > We now see in MariaDB 5.3 and beyond that changes have been made to
> > the timestamp field, such that the length of the field may be
> > something other than 1, 2, 3, 4,or 8 bytes.
> >
> > Given a timestamp field of N bytes, how are we meant to compare them?
> > Are some meant to be integer comparisons? Are others supposed to be
> > memory comparisons?
>
> It's stored as 4-byte bigendian number of the integer part of the
> timestamp, and then as 0- to 4-byte bigendian number for the fractional
> part. Because both parts are stored as bigendian numbers, I suppose, you
> can compare timestamps either as numbers or with memcmp.
>
> See Field_timestamp_hires::store_TIME().
>
> But really the API-correct way is to use Field::key_type() method and
> compare the values using the specified method. It's more future-proof
> than to hard-code comparison method mapping based on the field types.
>
> Regards,
> Sergei
>

Follow ups

References