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

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

From: Matthew Draper <matthew(at)trebex(dot)net>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: Allow SQL-language functions to reference parameters by parameter name
Date: 2012-01-29 09:08:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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;
> 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?




In response to


pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2012-01-29 12:27:32
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Previous:From: Dean RasheedDate: 2012-01-29 07:47:28
Subject: Index-only scan performance regression

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