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

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to

Browse pgsql-hackers by date

  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