Re: WITH ORDINALITY versus column definition lists - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: WITH ORDINALITY versus column definition lists
Date
Msg-id CAEZATCXTV+pmC_r0Hmu=n2kUrTC3CU7o+PEgJ=U=0Rc905R3NA@mail.gmail.com
Whole thread Raw
In response to Re: WITH ORDINALITY versus column definition lists  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: WITH ORDINALITY versus column definition lists  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 20 November 2013 22:46, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> 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.
>

Yeah that seems preferable to option #2, which just seems to open up a
whole can of worms.

However, I think I would quickly find it a PITA that it kept telling
me to wrap it in a TABLE() construct. It would seem like the "TABLE"
was just an unnecessary noise word (from a user perspective). Could we
simply support an alias list after the ORDINALITY, in addition to the
coldeflist? For example:

select * from array_to_set(array['one', 'two']) as (f1 int,f2 text)
with ordinality as t(a1,a2,a3);

That could be regarded as an implicit TABLE() construct, but the
syntax would be closer to the non-coldeflist case:

[ LATERAL ] function_name ( [ argument [, ...] ] ) [ WITH ORDINALITY ] [ [ AS ] alias [ ( column_alias [, ...] ) ] ]

[ LATERAL ] function_name ( [ argument [, ...] ] ) [ AS ] [ alias ] ( column_definition [, ...] ) [ WITH ORDINALITY ] [
[AS ] alias [ ( column_alias [, ...] ) ] ]
 

Regards,
Dean



pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: new unicode table border styles for psql
Next
From: Rushabh Lathia
Date:
Subject: Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL