maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Richa!

On Mar 14, Richa Sehgal wrote:
> Thanks Sergei for the explanation. The modified project for MDEV-5199
> (Table Functions) now makes sense - as in the proposals mentioned in the
> ticket as possible solutions now looks appropriate :)
> 
> I am looking into the index of virtual columns. One question: can we submit
> proposals for 2 projects at MariaDB?

We don't mind, but rules are set by Google, if they allow it - you can,
otherwise you cannot.

> Now as for Table Functions:
> 
> As mentioned there are two ways:
> 1. Materializing the table - this has a disadvantage for extra space.
> 2. Treating the UDF result as an "abstract table". For eg, the code might
> have a base class called Table. Then we can create a derived class called
> UDFTable and pass this instance in the regular query processing. This class
> would implement all functionalities like Init(), Next(), Read(int
> col_index), Seek(), etc
> Consider:
>  Select A where A.x > 10 FROM UDF_TABLE
> 
> In this case, we will first construct the table UDF_TABLE through regular
> query - evaluation of the UDF. Then we can create an instance of UDFTable
> from the table and run normal query processing on this.
> 
> Is this the right approach? Can you send me the next steps?

the "abstract table" that can do Next, Read, Seek, etc in MariaDB is
represented by the "handler" class. All real storage engines inherit
from the handler class.

See the SEQUENCE engine, it's in the storage/sequence/sequence.cc
This is, exactly, the engine that generates data on the fly, so is a
table function, in a sense. But it's a hard-coded function and the way
of passing arguments is not very nice. Still, it'll give you an idea
what a table function handler might look like.

If you want an even simpler storage engines - there are some in our
book, "MySQL 5.1 Plugin Development".

Regards,
Sergei