Re: mixed, named notation support - Mailing list pgsql-hackers

From Robert Haas
Subject Re: mixed, named notation support
Date
Msg-id 603c8f070908030938g74a68354scbdf77f81e526be2@mail.gmail.com
Whole thread Raw
In response to Re: mixed, named notation support  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: mixed, named notation support  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: mixed, named notation support  (Steve Prentice <prentice@cisco.com>)
Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
On Mon, Aug 3, 2009 at 10:51 AM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
> 2009/8/3 Steve Prentice <prentice@cisco.com>:
>> On Aug 3, 2009, at 1:41 AM, Pavel Stehule wrote:
>>
>>> I should to wait with Steve patch - I would to add main sql parser
>>> into plpgsql - than Steve's patch is unnecessary. But if there will be
>>> some problems, then we can use Steve's patch. It is simple - so there
>>> are not big problems with commit.
>>
>> I was hoping we could get the small patch into plpgsql during this
>> commitfest. This makes plpgsql recognize 'AS' and not replace named
>> parameter labels with the variable reference. I understand there is an
>> effort underway to redo the plpgsql parser, but getting these two patches in
>> together will allow people to start playing with plpgsql + named parameters
>> at the end the of commitfest when the first alpha is released. (You can use
>> named parameters + plpgsql without this patch, but not without some pretty
>> serious limitations.)
>>
>> Without this patch, this will fail:
>>
>> create function create_user(alias text, display_name text) returns void as
>> $$
>>  BEGIN
>>    perform create_alias(alias AS alias);
>>    ...
>>  END
>> $$ language plpgsql;
>>
>> This is a common pattern for many of the stored procedures we are porting
>> and I'd imagine it's common elsewhere too. If the plpgsql parser patch
>> lands, this patch won't be needed, but it's hard to predict when it will
>> land.
>>
>> As an aside, this pattern really shows how confusing the AS syntax can be
>> for named parameters. Which side is the label and which is the value?
>>
>
> ok - I don't though about it. My goal is integration main parser next
> commitfest, but it is true, so somebody would to play with named
> params now. Commiting of Steve's patch doesn't break anything.

I'm a little confused here.  We are 19 days into a 31 day CommitFest;
you are almost three weeks too late to add a patch to the queue.
Unless you can convince a friendly committer to pick this up out of
sequence, I think the only patch that is under consideration here is
the one that has been being discussed on this thread for the last 17
days.  I sent several notes adding for all patches to be added to
commitfest.postgresql.org prior to the start of CommitFest; AFAIK,
this one was never added.

You haven't actually specified which other patch of Steve's you're
talking about anyway, but I'm guessing it's this one here:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00801.php

I don't think that patch would get applied even if HAD been added to
the CommitFest page in time, see Tom's remarks here:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00802.php

Let's get back to focusing on the patch that is actually under
consideration here.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Split-up ECPG patches
Next
From: Tom Lane
Date:
Subject: Re: Alpha releases: How to tag