Hi, Alexey! On Nov 14, Alexey Botchkov wrote:

Hi, Serg.

I'd like your opinion about this issue. Georg complains about weird column metadata https://jira.mariadb.org/browse/MDEV-10173

Personally i see slightly different result, but basically same thing. -------------------------------- MariaDB [(none)]> select from_unixtime("0"); Field 1: `from_unixtime("0")` Catalog: `def` Database: `` Table: `` Org_table: `` Type: DATETIME Collation: binary (63) Length: 26 Max_length: 19 Decimals: 39 Flags: BINARY

Right, I get used to 31 being NOT_FIXED_DEC. But recently Monty changed it to 39.

+---------------------+ | from_unixtime("0") | +---------------------+ | 1970-01-01 04:00:00 | +---------------------+ 1 row in set (0.00 sec) --------------------------------

From what i see it is not a bug. The 'Decimals: 39' is not a real precision here, but just a hint to be flexible converting the data to the string. The 'Length: 26' takes into account the possible 'second_part' of 6 digits.

Agree.

Georg said on this: "Well, the client "trusts" the metadata. If there is decimal 31, it appends 31 decimal places and returned truncation error the metadata (MYSQL_FIELD) describes the data which are sent from server to client. If there are no decimal places, it should be zero. "

Yes, the cient trusts the metadata, but if decimals is NOT_FIXED_DEC it means "unknown", not 31 (or 39). If the number of decimals for a timestamp is unknown, the max length is 26: "YYYY-MM-DD hh:mm:ss.uuuuuu"

As an improvement i can see using '7' instead of '39' as an 'NOT_FIXED_DEC' marker for the Item_temporal_func.

Why? One wouldn't be able simply to compare with NOT_FIXED_DEC, it'll be type dependent.

Or we can just document that '39' value so clients interpret it right.

Isn't it documented?

Serg, maybe you can suggest something?

Close as "Not a bug" :) Regards, Sergei Chief Architect MariaDB and security@mariadb.org