Re: Patch: Allow SQL-language functions to reference parameters by parameter name
От | Hitoshi Harada |
---|---|
Тема | Re: Patch: Allow SQL-language functions to reference parameters by parameter name |
Дата | |
Msg-id | CAP7Qgmn97hqi7PCe4TSZB3VxtmhQTn6ZpZJC+iRBOXZLNgnzkg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch: Allow SQL-language functions to reference parameters by parameter name (Matthew Draper <matthew@trebex.net>) |
Список | pgsql-hackers |
On Sun, Jan 29, 2012 at 1:08 AM, Matthew Draper <matthew@trebex.net> wrote: > 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. Makes sense to me. I marked this as Ready for committer. Thanks, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: