Re: Implementing SQL/PSM for PG 8.2

From: Neil Conway <neilc(at)samurai(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Denis Lussier <denis(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implementing SQL/PSM for PG 8.2
Date: 2005-06-28 00:40:41
Message-ID: 42C09C89.3030805@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
> The whole parser is a hack that attempts to parse the procedural parts
> of the function but preserving the SQL parts as query strings while
> substituting variables with numbered parameters. That is anything but
> clean. It was the only way I saw at the time of implementation to build
> a parser that automatically supports future changes of the main Postgres
> query language.

I agree the current parser is a hack, but it's difficult to see how else
it could be implemented. One possibility I've mentioned in the past is
to rewrite the main SQL parser by hand (e.g. as a recursive descent
parser), so that we could directly call into the main SQL parser from
the PL/PgSQL parser. I believe that would let us embed SQL in PL/PgSQL
without needing to teach the PL/PgSQL anything about the main SQL
grammar. But of course this has the downside of needing to write and
maintain a recursive descent parser.

Any better ideas?

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-06-28 00:55:05 language handlers in public schema
Previous Message Neil Conway 2005-06-28 00:28:02 Re: Implementing SQL/PSM for PG 8.2