Re: proposal sql: labeled function params - Mailing list pgsql-hackers

From daveg
Subject Re: proposal sql: labeled function params
Date
Msg-id 20080823224835.GS28154@sonic.net
Whole thread Raw
In response to Re: proposal sql: labeled function params  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: proposal sql: labeled function params  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-hackers
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 
> > Hello
> >
> > 2008/8/23 Peter Eisentraut <peter_e@gmx.net>:
> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
> >>> If we're really worried about it we can have a GUC for a few versions
> >>> that turns off named parameter assignment. But I don't think we
> >>> should compromise the design on the theory that some folks might be
> >>> using that as an operator *and* can't change their application to
> >>> wrap it's use in ().
> >>
> >> Even if that were a reasonable strategy, you can't use GUC parameters to alter
> >> parser behavior.
> >
> > I thing, so it's possible - in this case. We should transform named
> > params to expr  after syntax analyze.
> 
> So for a bit of useless syntactic sugar we should introduce conflicts with
> named parameters, conflicts with operators, introduce an un-sqlish syntax and
> remove a feature users have already made use of and introduce backwards
> compatibility issues for those users?
> 
> At any point in this discussion has anyone explained why these labels would
> actually be a good idea?

I was missing that too. What is this for that makes it so compelling?

-dg

-- 
David Gould       daveg@sonic.net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: What in the world is happening on spoonbill?
Next
From: Tom Lane
Date:
Subject: Re: What in the world is happening on spoonbill?