maria-developers team mailing list archive
Mailing list archive
Re: Exposing Item::store_native and val_native to the SQL layer
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 (
> ) to use these new API functions.
> I've only just started on this task (
> ) 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
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:
and to modify classes:
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!
> 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