maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

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/dcc7ccf65689bd7d84bef37c0985c03fa7a7cb13
> ) 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
> 
> --