>> We talked about this during PGCon. The idea that seemed to have >> consensues there was to export the parser similarly to how we build >> the ecpg parser, that is, a set of perl scripts which take our >> gram.y as input and modify it to emit something different. > > That solves the non-customized part of the problem, which is worth > solving.
In addition to this, parsing SQL may need tree walker functions and some support functions(e.g. memory management). These are source files from pgpool-II's parser directory. copyfuncs.c kwlist.h nodes.c pg_list.h pool_string.h value.c gram.c kwlookup.c nodes.h pg_wchar.h primnodes.h value.h gram.h list.c outfuncs.c pool_memory.c scan.c wchar.c gramparse.h makefuncs.c parsenodes.h pool_memory.h scanner.h keywords.c makefuncs.h parser.c pool_parser.h scansup.c keywords.h memnodes.h parser.h pool_string.c scansup.h > A complete parser for a given DB would need catalog access, > i.e. a live connection to that DB. Yes, pgpool-II does some of this. (for example, to know if particular table is a tempory table, to expand "*" to real column lists and so on). Just F.Y.I. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
