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

From Steve Prentice
Subject Re: mixed, named notation support
Date
Msg-id 9BCF79DE-8746-4C93-96B6-2A943FDDD023@cisco.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>)
List pgsql-hackers
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?

Thanks,
-Steve


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: CVS Head parser error?
Next
From: Pavel Stehule
Date:
Subject: Re: mixed, named notation support