On Mon, Sep 14, 2009 at 11:56 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2009/9/14 Steve Prentice <prentice@cisco.com>:
>> On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
>>
>>> 2009/9/14 Tom Lane <tgl@sss.pgh.pa.us>:
>>>>
>>>> Robert Haas <robertmhaas@gmail.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
