2009/8/3 Steve Prentice <prent...@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. Pavel > Thanks, > -Steve > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
