Hi Eric, On 02/24/2019 07:55 PM, Eric Herman wrote:

Hello Bar,

As you have done the work on store_native and val_native, I would especially like to know your thoughts with regards to how to expose these to the SQL layer.

In my particular case, I'd like to re-work the "Add FLOAT and DOUBLE data interchange functions" patch ( https://github.com/ericherman/mariadb-server/commit/dcc7ccf65689bd7d84bef37c... ) to use these new API functions.

I've only just started on this task ( https://github.com/ericherman/mariadb-server/tree/10.4-eherman-float-native ) and first thing that I need to figure out is how to write the tests.

In commit 34eb98387f8f46a80fb053081dbe20d415f23b39 ( MDEV-13995 MAX(timestamp) returns a wrong result near DST change ), I see that in tests the SQL calls various time functions which ultimately call into these functions, yet I do not see any way to access these two new functions directly.

Are you thinking of adding new SQL functions to expose the underlying bytes to the user? If not, I have a sense that casting to and from BINARY could expose the native byte arrays, but I'm not sure if that's the direction you imagine.

Yes, I thought we would expose the underlying bytes to the user through a new SQL function, eventually. However, from a glance, it's not strictly necessary for your task. We need for sure the following: 1. Fix Type_handler_float to transfer values inside the server using the native raw format, rather than double. The patch for float should be very similar to what 34eb98387f8f46a80fb053081dbe20d415f23b39 did: it split Timestamp from Datetime. Now we need to split float from double the same way. We'll need to introduce new classes for this: - Item_cache_float - Item_float_literal - in_float - cmp_item_float and to modify classes: - Field_float - Type_handler_float 2. Add a way to specify FLOAT literals: Introduce a float literal syntax, e.g.: SELECT float_column=FLOAT'10.123' FROM t1; SELECT float_column=FLOAT'10.123e0' FROM t1; SELECT float_column=FLOAT'1.0123e1' FROM t1; to parse values directly to FLOAT (without having any DOUBLE intermediate values during conversion) and make Item_float_literal, rather than Item_double. 3. Optionally, for completeness, we can add a new syntax CAST(AS FLOAT): So this query: SELECT float_column=CAST(expr AS FLOAT) FROM t1; converts expr directly to FLOAT (without having any DOUBLE intermediate values during conversion). By the way, I haven't added CAST(expr AS TIMESTAMP) yet. Probably I should do it soon. Some low level float parsing and conversion routines will be needed to implement #2 and #3.

If you tell me which direction to go, I will try to make that happen.

Thanks for your interest in this topic!

Cheers, -Eric

Other foo_native related commits: * commit a8a757c6bb32bbf291afdf33df861127489889ab wl#173 - temporal types with sub-second resolution

* commit c353b2a8fc10e16107ee6c7e26877f4243d4eaef MDEV-17979 Assertion `0' failed in Item::val_native upon SELECT with timestamp, NULLIF, GROUP BY

--