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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
