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