Hi, Kesha!

On Mar 18, Kesha Shah wrote:
> Dear Sergei Golubchik,
>
> Hope this mail finds you well.
>
> I am Kesha Shah, a third year undergraduate from DA-IICT, Gandhinagar,
> India. I was a Google Summer of Code student previous year as well as
> Google Code-In mentor with BRL-CAD open source solid modeling
> software. The activities related to my contributions at BRL-CAD at
> logged by me at -
> http://brlcad.org/wiki/User:KeshaSShah/GSoC13/Reports. My other
> projects can be found at -
> https://github.com/keshashah?tab=repositories.
> I have good programming hands on C and C++ and would like to take up
> and contribute at the Mariadb task of 'CREATE OR REPLACE, CREATE IF
> NOT EXISTS, and DROP IF EXISTS' [MDEV-5359] as part of GSOC 2014. I
> have studied database systems and compiler construction during my
> academics. Your project would help to apply my knowledge by working at
> deeper level of coding database internals, thereby contributing to
> open source software.

Great.

> I had checked out the mariadb master branch from bazaar and started
> looking into the source code. I found the task more related to update
> of the existing mariadb SQL parser. The parser seems to be implemented
> as ascendant parser using bison parser generator (GNU version of
> YACC). From the current findings I could see the YACC grammar file
> sql_yacc.yy under maria/sql/ where I can see the rules defined for
> CREATE PROCEDURE_SYM, CREATE FUNCTION_SYM, CREATE TRIGGER_SYM etc.
> Alternatively I can see the *_SYM lexical tokens defined under the
> /maria/sql/lex.h file. Similarly for DROP TABLESPACE_SYM, DROP
> TRIGGER_SYM etc could be found. So when sql text input stream is
> encountered from SQL interface, it is read and categorized into
> lexical tokens by the lexer /maria/sql/sql_lex.cc in the lexical
> analysis step. I tried to figure out that we will have to define
> additional token 'IF' in the lex.h and 'NOT' and 'EXISTS' are already
> defined.

All three are already defined, look for CREATE TABLE IF NOT EXISTS, for
example.

> I am also looking at the existing user defined actions that
> builds the AST nodes (sp_head being the root node for most types) when
> relevant grammar rule is satisfied in case of DDL statements. After
> semantic analysis (create of stored procs/functions), the next step
> would be to amend/define actions for the newly introduced grammar of
> handling check of existence of db artefact at the time of DDL
> execution. Also at this step the compiler will have to query the
> relevant storage engine on DB level or repository level to check if
> the DB object exists. This would require me to spend more time on
> understanding design pattern followed for the implementation of
> classes and behaviours of each of the underlying db artefacts.
>
> It would be interesting for me to know if the steps proposed by me
> above are in the right direction or not ?  Also I am aware that I am

Yes, they look correct.

> late in discussing my proposal with you. But I can assure that I will
> be able to deliver the requirements in timely manner under your
> guidance. I have formulated initial draft of my proposal and would
> like to submit it at the earliest.

Regards,
Sergei