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-list extension that's at issue.
>
>> Not sure if this is possible at this point but really the alias for the
>> ordinality column would be attached directly to the ordinality keyword.
>
>> e.g., ...) with ordinality{alias} as t(a1, a2)
>
> This has no support in the standard.
Now I'm just spinning some thoughts:
) with ordinality AS t(a1 text, a2 text | ord1) -- type-less, but a
different separator
) with ordinality AS t(a1 text, a2 text)(ord1) -- stick it in its own
section, type-less
) with ordinality AS t(a1 text, a2 text) ordinal(ord1) --name the section
too
would probably want to extend the alias syntax to match...
Is there any precedent in other RDBMS to consider?
I don't see any obvious alternatives to the ones you listed and syntax is
really not a huge barrier. If the implementation of an optionally specified
alias is a barrier then either someone needs to feel strongly enough to
implement it or just default to #1 for the time being.
But others really haven't had a chance to read and respond yet so I'm gonna
get off this train for a while.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/WITH-ORDINALITY-versus-column-definition-lists-tp5779443p5779473.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
