Re: Implementing SQL/PSM for PG 8.2

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Denis Lussier <denis(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, Jan Wieck <JanWieck(at)yahoo(dot)com>
Subject: Re: Implementing SQL/PSM for PG 8.2
Date: 2005-06-28 01:02:23
Message-ID: 1119920543.4502.45.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2005-06-28 at 10:40 +1000, Neil Conway wrote:
> 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

Could the reverse be done? Combine the PL/PgSQL and SQL grammar for the
main parser (thus allowing procedural logic in standard SQL locations)
and perhaps for the other PLs they can hook into a specific statement
grammar which is a subset of the PL/PgSQL grammar by prefixing a keyword
-- say EXECUTE to their strings.

I would like to have some logic in psql, much as you can build simple
loops and logic with shell on the command line on the fly.
--

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-06-28 01:18:32 Re: commit_delay, siblings
Previous Message Andrew Dunstan 2005-06-28 00:55:05 language handlers in public schema