Re: proposal sql: labeled function params
От | Decibel! |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 46FB9762-82D5-45F0-AAC9-677DD5C96C8D@decibel.org обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal sql: labeled function params
Re: proposal sql: labeled function params |
Список | 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 по дате отправления: