From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WITH ORDINALITY versus column definition lists |
Date: | 2013-11-21 09:15:26 |
Message-ID: | CAEZATCXTV+pmC_r0Hmu=n2kUrTC3CU7o+PEgJ=U=0Rc905R3NA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20 November 2013 22:46, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rushabh Lathia | 2013-11-21 09:21:40 | Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL |
Previous Message | amul sul | 2013-11-21 08:23:20 | Re: new unicode table border styles for psql |