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

From Gregory Stark
Subject Re: proposal sql: labeled function params
Date
Msg-id 87myj3pvd2.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: proposal sql: labeled function params  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: proposal sql: labeled function params  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: proposal sql: labeled function params  (daveg <daveg@sonic.net>)
List pgsql-hackers
"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?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: WITH RECURSIVE patches 0818
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Surprising syntax error