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

From Matthew Draper
Subject Re: Patch: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id 4F250C8A.40507@trebex.net
Whole thread Raw
In response to Re: Patch: Allow SQL-language functions to reference parameters by parameter name  (Hitoshi Harada <umi.tanuki@gmail.com>)
Responses Re: Patch: Allow SQL-language functions to reference parameters by parameter name
Re: Patch: Allow SQL-language functions to reference parameters by parameter name
List 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@trebex.net


pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Index-only scan performance regression
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] Add GUC sepgsql.client_label