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: | 4F250C8A.40507@trebex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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;
> 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(at)trebex(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-01-29 12:27:32 | Re: [v9.2] Add GUC sepgsql.client_label |
Previous Message | Dean Rasheed | 2012-01-29 07:47:28 | Index-only scan performance regression |