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 <s...@askmonty.org> 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 >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
