Re: proposal: new contrib module plpgsql's embeded sql validator

>> 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