Dear Sergei and Maria community,

Finally I have settled on one project: Indexing over virtual columns.

I spent the entire day today trying to compile MariaDB in Ubuntu and reading the code. On reading code side, I spent some time in the /storage/myiasm/ : read fiels like mi_key.cc, mi_create.cc, ha_myisam and so on. Took a brief overview arounf _mi_make_key function. I also looked around update_virtual_fields() function.

The code path is still not very clear to me - especially the transition point between sql folders to /storage folders. I chatted on #maria IRC and they gave an idea to run Maria in gdb mode. I tried compiling the code it was almost successful! At the very final step, I got the following error:

[ 98%] Built target thr_lock
Linking CXX shared library libmysqlclient.so
/usr/bin/ld: error: /home/shikhar/mariadb/maria/trunk/libmysql/libmysql_versions.ld:155:9: invalid use of VERSION in input file
collect2: ld returned 1 exit status
make[2]: *** [libmysql/libmysqlclient.so.18.0.0] Error 1
make[1]: *** [libmysql/CMakeFiles/libmysql.dir/all] Error 2
make: *** [all] Error 2

I am not able to proceed now. I tred googling around, but could not find the fix. Can you please guide me in my next steps?

Thanks

Richa

On Sat, Mar 14, 2015 at 10:46 AM, Sergei Golubchik <serg@mariadb.org> wrote:

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