Re: [PATCH] 8.5 plpgsql change for named notation: treat word following AS keyword as label v3

On Mon, Sep 14, 2009 at 11:56 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2009/9/14 Steve Prentice <prentice(at)cisco(dot)com>:
>> On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
>>
>>> 2009/9/14 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>>
>>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>>>
>>>>> So, I guess I'm sadly left feeling that we should probably reject this
>>>>> patch.  Anyone want to argue otherwise?
>>>>
>>>> +1.  I'm really hoping to get something done about the plpgsql parsing
>>>> situation before 8.5 is out, so this should be a dead end anyway.
>>>>
>>>
>>> I have a WIP patch for integration main SQL parser to plpgsql. I'll
>>> send it to this weekend.
>>
>> I certainly don't mind the patch getting rejected and agree that refactoring
>> the plpgsql parser is probably the best approach to this issue. However, I
>> think it would be more than a little strange to ship the named notation
>> feature without a solution for this problem. For reference, the problem is
>> that the function below causes a compile error because of the way plpgsql
>> blindly does variable replacement:
>>
>> create function fun1(pDisplayName text) returns void as $$
>> begin
>>    perform fun2(pDisplayName as pDisplayName);
>> -- Above line compiles as:
>> --  SELECT  fun2( $1  as  $1 )
>> end
>> $$ language plpgsql;
>>
>
> I am sure, so this this will be solved in next commitfest. This
> problem is related only to plpgsql. Other PL languages are well,
> because doesn't try to emulate SQL parser.

And the emphasis here is on "try".

...Robert