From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | david(at)fetter(dot)org |
Cc: | alvherre(at)commandprompt(dot)com, jim(at)nasby(dot)net, pavel(dot)stehule(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal: new contrib module plpgsql's embeded sql validator |
Date: | 2011-07-19 02:46:48 |
Message-ID: | 20110719.114648.244414910322696865.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Kupershmidt | 2011-07-19 02:57:24 | Re: patch: Allow \dd to show constraint comments |
Previous Message | Simon Riggs | 2011-07-19 02:44:09 | pgsql: Cascading replication feature for streaming log-based replicatio |