Re: proposal: SQL parser integration to PL/pgSQL

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: SQL parser integration to PL/pgSQL
Date: 2009-05-25 10:18:04
Message-ID: 162867790905250318v4d9db7dak826a2f68d955ba97@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/5/25 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 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
>

the problem is place for hook variable - it should be in ParseState
because we need call hooked functions from environments that install
hook.

Pavel

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2009-05-25 10:24:59 Re: generic options for explain
Previous Message Kolb, Harald (NSN - DE/Munich) 2009-05-25 10:10:16 Re: Synchronous replication: Promotion of Standby to Primary