maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

  Hello all,


I have mostly implemented the server side part of the fixed length
16-byte INET6 data type (only some clean-ups left).
MDEV-274 The data type for IPv6/IPv4 addresses in MariaDB
https://mariadb.atlassian.net/browse/MDEV-274


I made it in a very new style, which is ready to data type plugins,
as described in:
MDEV-4912 Add a plugin to field types (column types)
https://mariadb.atlassian.net/browse/MDEV-4912


It is done by introducing a new abstract super-class Type_handler
with a number of virtual public methods
(around 50 public methods at this point).


To implement a new data type one just needs to implement an
instantiable class derived from Type_handler and register the
new data type in a special global registry.


Everything start to work automatically, including (but not limited to):
- correct comparison
- hybrid type functions like COALESCE, LEAST
- aggregate functions MAX() and MIN()
- CAST to the new type
- ORDER BY, both for field and for items
- conversion to the standard data types
- indexing and index search


The definition of the instantiable class that actually implements INET6
looks like this:


class Type_handler_inet6: public Type_handler
{
private:
  class Field_inet6: public Field
  {
  ...
  };
  class Arg_comparator_inet6: public Arg_comparator
  {
  ...
  };
  class Item_typecast_inet6: public Item_func
  {
  ...
  };
public:
  // various access methods
};


It looks very nice for me so far :)


I have some questions about the remaining things:


1. In my current patch the new data type INET6 is not loaded
dynamically from a shared library. It's implemented inside mysqld.
Is it Okey? Or would we prefer to make it as a plugin from the
beginning? (in this case there's some more work left: the dynamic
loader code, client-server protocol, PS protocol).


2. In case of pluggable data types we'll need some changes in the
client-server protocol, to transfer data type names (and probably some
more metadata) to the client side in some textual form.
Any ideas on that?


3. PS protocol obviously needs two ways to bind data:
in text format and in binary format. For example, in case of INET6
it would be nice to be able to bind parameters and fetch values using:
- text representation "ffff::ffff"
- and binary representation 0xFFFF000000000000000000000000FFFF.

I can see some ways to do this:
a. Every pluggable data type uses its own type code in MYSQL_BIND:

  char ip6[16]= "\xff\xff...\xff";
  MYSQL_BIND bind;
  bind.buffer_type= 128; // This is INET6
  bind.buffer= ip6;
  bind.length= sizeof(ip6);

  but the code (128) may vary between servers,
  depending on how the plugin is installed.


b. Or we could introduce a singe new type code MYSQL_TYPE_RAW:
  char ip6[16]= "\xff\xff...\xff";
  MYSQL_BIND bind;
  bind.buffer_type= MYSQL_TYPE_RAW;
  bind.buffer= ip6;
  bind.length= sizeof(ip6);

  The server should be able to treat a single type code with
  different data types without any problems, because it knows
  the parameter context.
  But this will not allow to mix values of different types though,
  for example insert an INET4 value into an INET6 column
  (or vice verse) won't be possible.

c. Or we could support both "native" type codes and MYSQL_TYPE_RAW.


4. Do we need the INET4 data type (fixed length, 4 bytes)?

5. Do we need a PostgreSQL-alike INET data type which is able
  to store both INET4 and INET6 values (I guess this one should
  be variable length: 4-bytes for INET4 and 16 bytes for INET6 values.


Any feedback would be appreciated.


The current patch (attached) will be polished.
but the general idea should already be clear from the current version.


Thanks.

Attachment: inet26.diff.gz
Description: GNU Zip compressed data