From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Steve Prentice <prentice(at)cisco(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mixed, named notation support |
Date: | 2009-08-03 16:38:48 |
Message-ID: | 603c8f070908030938g74a68354scbdf77f81e526be2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 3, 2009 at 10:51 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2009/8/3 Steve Prentice <prentice(at)cisco(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-03 16:44:47 | Re: Alpha releases: How to tag |
Previous Message | Tom Lane | 2009-08-03 16:23:39 | Re: Split-up ECPG patches |