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: 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

In response to

Responses

Browse pgsql-hackers by date

  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