Re: proposal: SQL parser integration to PL/pgSQL

2009/5/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>