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
Re: mixed, named notation support Re: mixed, named notation support Re: mixed, named notation support |
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: