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

From Decibel!
Subject Re: proposal sql: labeled function params
Date
Msg-id 46FB9762-82D5-45F0-AAC9-677DD5C96C8D@decibel.org
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  (Hannu Krosing <hannu@2ndQuadrant.com>)
Re: proposal sql: labeled function params  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
> 2008/8/20 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> I understand now why Oracle use => symbol for named params. This  
>>> isn't
>>> used so operator - so implementation is trivial.
>>
>> You really didn't understand the objection at all, did you?
>>
>> The point is not about whether there is any built-in operator  
>> named =>.
>> The point is that people might have created user-defined operators  
>> named
>> that.
>
> I understand well, so only I don't see better solution. Yes, everyone
> who used => should have problems, but it is similar with .. new
> keywords, etc. Probably easy best syntax doesn't exist :(. I  haven't
> idea who use => now and how often, and if this feature is possible in
> pg, but there are not technical barriers.


How about we poll -general and see what people say? I'll bet Tom a  
beer that no one replies saying they've created a => operator (unless  
maybe PostGIS uses it).

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 ().
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828



pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: [GENERAL] Surprising syntax error
Next
From: Decibel!
Date:
Subject: Re: [DOCS] [ADMIN] shared_buffers and shmmax