Re: proposal sql: labeled function params
| От | Gregory Stark |
|---|---|
| Тема | Re: proposal sql: labeled function params |
| Дата | |
| Msg-id | 87ljyvwm6a.fsf@oxford.xeocode.com обсуждение исходный текст |
| Ответ на | Re: proposal sql: labeled function params ("Pavel Stehule" <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
"Pavel Stehule" <pavel.stehule@gmail.com> writes: > 2008/8/17 Hannu Krosing <hannu@2ndquadrant.com>: >> On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote: >>> 2008/8/16 Decibel! <decibel@decibel.org>: >>> > SQL-like would be value AS name, but I'm not a fan of putting the value >>> > before the name. And I think value AS name will just lead to a ton of >>> > confusion. >>> > >>> > Since I think it'd be very unusual to do a => (b => c), I'd vote that we >>> > just go with =>. Anyone trying to do a => b => c should immediately question >>> > if that would work. >>> >>> I'll look on this syntax - what is really means for implementation. I >>> thing, mostly of us prefer this or similar syntax. >> >> Actually the most "natural" syntax to me is just f(name=value) similar >> to how UPDATE does it. It has the added benefit of _not_ forcing us to >> make a operator reserved (AFAIK "=" can't be used to define new ops) This whole thing seems like a ridiculous idea. It's a fancy way of passing an extra parameter to the function intended to be used for a particular "label" purpose. Your xml function could just as easily take two functions f(name,value) instead of using a special spelling for ",". That it is easily confused with named parameters means there are huge downsides and no significant up-sides to having this trivial little bit of syntactic sugar. To say nothing that using "=>" or anything like that would be just completely un-SQLish. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
В списке pgsql-hackers по дате отправления: