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

From Pavel Stehule
Subject Re: proposal: SQL parser integration to PL/pgSQL
Date
Msg-id 162867790905242329gc0e0829u8f49462d44458c61@mail.gmail.com
Whole thread Raw
In response to Re: proposal: SQL parser integration to PL/pgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: SQL parser integration to PL/pgSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
2009/5/24 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.

good idea

>
> 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.
>

ok

>> 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.
>

there is minimal one necessary - for polymorphic variables, we know
name, but we don't know type. And without types, we can't to transform
correctly functions.

regards
Pavel Stehule


>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Joshua Tolley
Date:
Subject: Re: generic options for explain
Next
From: Pavel Stehule
Date:
Subject: Re: generic options for explain