Re: Patch: Allow SQL-language functions to reference parameters by parameter name
| От | Matthew Draper |
|---|---|
| Тема | Re: Patch: Allow SQL-language functions to reference parameters by parameter name |
| Дата | |
| Msg-id | 4F250C8A.40507@trebex.net обсуждение исходный текст |
| Ответ на | Re: Patch: Allow SQL-language functions to reference parameters by parameter name (Hitoshi Harada <umi.tanuki@gmail.com>) |
| Ответы |
Re: Patch: Allow SQL-language functions to reference
parameters by parameter name
Re: Patch: Allow SQL-language functions to reference parameters by parameter name |
| Список | pgsql-hackers |
On 25/01/12 18:37, Hitoshi Harada wrote: >> I'm still not sure whether to just revise (almost) all the SQL function >> examples to use parameter names, and declare them the "right" choice; as >> it's currently written, named parameters still seem rather second-class. > > Agreed. I'll try a more comprehensive revision of the examples. > The patch seems ok, except an example I've just found. > > db1=# create function t(a int, t t) returns int as $$ select t.a $$ > language sql; > CREATE FUNCTION > db1=# select t(0, row(1, 2)::t); > t > --- > 1 > (1 row) > > Should we throw an error in such ambiguity? Or did you make it happen > intentionally? If latter, we should also mention the rule in the > manual. I did consider it, and felt it was the most consistent: # select t.x, t, z from (select 1) t(x), (select 2) z(t);x | t | z ---+---+-----1 | 2 | (2) (1 row) I haven't yet managed to find the above behaviour described in the documentation either, though. To me, it feels like an obscure corner case, whose description would leave the rules seeming more complicated than they generally are. Maybe it'd be better suited to be explicitly discussed in the comments? Thanks, Matthew -- matthew@trebex.net
В списке pgsql-hackers по дате отправления: