Re: proposal sql: labeled function params
От | Hannu Krosing |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 1219521008.26201.2.camel@huvostro обсуждение исходный текст |
Ответ на | 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 Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote: > Hello > > 2008/8/22 Hannu Krosing <hannu@2ndquadrant.com>: > > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote: > >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote: > > > >> 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). > > > > Does Oracle use => for "labeled function params" or just named > > arguments ? > > > > Oracle use it for named arguments - what I know, similar it doesn't > allow functionality as labeled params publicly - SQL/XML use 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 (). > > > > I still think that better approach is allowing RECORD as input type and > > do all the things Pavel proposed with a function that iterates over > > record. > > > > record or hash table - it's implementation - second step. We have to > find syntax and semantic now. Why not just use some standard record syntax, like SELECT(value::type name, ...) or perhaps some extended ROW() or VALUES() syntax ? Like this : SELECT * FROM FUNC(SELECT(value::type name, ...) AS r); ----------------- Hannu
В списке pgsql-hackers по дате отправления: