Re: proposal: SQL parser integration to PL/pgSQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: SQL parser integration to PL/pgSQL
Date
Msg-id 10752.1243196563@sss.pgh.pa.us
Whole thread Raw
In response to proposal: SQL parser integration to PL/pgSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: SQL parser integration to PL/pgSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> ==Steps==
> 1. add hook to analyser (transform stage) to substitute unknown
> columnref by param - when analyser detect unknown columnref, then call
> callback, that returns possible para node or NULL (when external
> environment doesn't have a variable). Returned param should be typed
> or unknown (for polymorphic params).

IMHO the hook definition should support both the case of external
variables taking precedence over query variables and vice versa.
I don't think the core parser should be forcing that decision.  In any
case we'd probably need both options for plpgsql, so as to be able to
support both traditional and Oracle-compatible behavior.

I'd be inclined to do that by letting the hook function interpose
itself between the parser and the regular transformColumnRef processing,
so that it can call the regular transformColumnRef processing either
before or after doing its external lookups.  Giving it control only
after the regular processing fails would mean there's no way to let
external variables take precedence.

> 2. add special modes to sql parser:

None of those seem like a good idea to me.  The only part that seems
useful is warning about conflicts between external variables and query
variables.  That can be implemented by the hook function itself, if we
define the hook behavior as above.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ben Ali Rachid
Date:
Subject: Re: Oracle to Postgres : create type as object in Postgres
Next
From: Gevik Babakhani
Date:
Subject: pg_class and enum types