Re: Patch: Allow SQL-language functions to reference parameters by parameter name - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Patch: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id CAP7Qgmn97hqi7PCe4TSZB3VxtmhQTn6ZpZJC+iRBOXZLNgnzkg@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Allow SQL-language functions to reference parameters by parameter name  (Matthew Draper <matthew@trebex.net>)
List 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 by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage