Dean Rasheed writes:
> On 20 November 2013 22:46, Andrew Gierth wrote:
> "Tom" == Tom Lane writes:
>> Tom> 1. Reinsert HEAD's prohibition against directly combining WITH
>> Tom> ORDINALITY with a coldeflist (with a better error message and a
>> Tom> HINT suggesting that you can get what you want
On 20 November 2013 22:46, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
>
> Tom> 1. Reinsert HEAD's prohibition against directly combining WITH
> Tom> ORDINALITY with a coldeflist (with a better error message and a
> Tom> HINT suggesting that you can get what you want via the TABLE
>
> "Tom" == Tom Lane writes:
Tom> 1. Reinsert HEAD's prohibition against directly combining WITH
Tom> ORDINALITY with a coldeflist (with a better error message and a
Tom> HINT suggesting that you can get what you want via the TABLE
Tom> syntax).
That gets my vote.
--
Andrew (irc:Rhodium
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>> Just to clarify we are still allowing simple aliasing:
>
>> select * from generate_series(1,2) with ordinality as t(f1,f2);
>
> Right, that works (and is required by spec, I believe). It's what to
> do with our column-definition-lis
David Johnston writes:
> Just to clarify we are still allowing simple aliasing:
> select * from generate_series(1,2) with ordinality as t(f1,f2);
Right, that works (and is required by spec, I believe). It's what to
do with our column-definition-list extension that's at issue.
> Not sure if th
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>> Tom Lane-2 wrote
>>> It seems to me that we don't really want this behavior of the coldeflist
>>> not including the ordinality column. It's operating as designed, maybe,
>>> but it's unexpected and confusing. We could either
>>>
>>>
David Johnston writes:
> Tom Lane-2 wrote
>> It seems to me that we don't really want this behavior of the coldeflist
>> not including the ordinality column. It's operating as designed, maybe,
>> but it's unexpected and confusing. We could either
>>
>> 1. Reinsert HEAD's prohibition against dir
Tom Lane-2 wrote
> It seems to me that we don't really want this behavior of the coldeflist
> not including the ordinality column. It's operating as designed, maybe,
> but it's unexpected and confusing. We could either
>
> 1. Reinsert HEAD's prohibition against directly combining WITH ORDINALITY
Consider the following case of a function that requires a column
definition list (example borrowed from the regression tests):
create function array_to_set(anyarray) returns setof record as $$
select i AS "index", $1[i] AS "value" from generate_subscripts($1, 1) i
$$ language sql strict immutabl
