Skip site navigation (1) Skip section navigation (2)

Re: Patch: Allow SQL-language functions to reference parameters by parameter name

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Matthew Draper <matthew(at)trebex(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: Allow SQL-language functions to reference parameters by parameter name
Date: 2012-01-30 08:42:26
Message-ID: CAP7Qgmn97hqi7PCe4TSZB3VxtmhQTn6ZpZJC+iRBOXZLNgnzkg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jan 29, 2012 at 1:08 AM, Matthew Draper <matthew(at)trebex(dot)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

In response to

pgsql-hackers by date

Next:From: Kyotaro HORIGUCHIDate: 2012-01-30 09:06:57
Subject: Re: Speed dblink using alternate libpq tuple storage
Previous:From: Alexander KorotkovDate: 2012-01-30 07:31:49
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group