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.
> 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);
>> (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
> 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.
In response to
pgsql-hackers by date
|Next:||From: Kyotaro HORIGUCHI||Date: 2012-01-30 09:06:57|
|Subject: Re: Speed dblink using alternate libpq tuple storage|
|Previous:||From: Alexander Korotkov||Date: 2012-01-30 07:31:49|
|Subject: Re: GiST for range types (was Re: Range Types - typo + NULL