From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: UNNEST (and other functions) WITH ORDINALITY |
Date: | 2013-06-21 07:02:44 |
Message-ID: | CAEZATCUEGv1PMn82imyMg3eUGPtjDg4f=++Fc7ek5Nt3dNjypw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21 June 2013 06:54, David Fetter <david(at)fetter(dot)org> wrote:
>> For example "SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file"
>
> The spec is pretty specific about the "all or none" nature of naming
> in the AS clause...unless we can figure out a way of getting around it
> somehow.
We already support and document the ability to provide a subset of the
columns in the alias. I didn't realise that was beyond the spec, but
since we already have it...
> I'm weighing in on the side of a name that's like ?columnN? elsewhere
> in the code, i.e. one that couldn't sanely be an actual column name,
> whether in table, view, or SRF.
I don't think we need to be overly concerned with coming up with a
unique name for the column. Duplicate column names are fine, except if
the user wants to refer to them elsewhere in the query, in which case
they need to provide aliases to distinguish them, otherwise the query
won't be accepted.
I'd be happy if you just replaced "?column?" with ordinality in a
couple of places in your original patch.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2013-06-21 07:19:51 | Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) |
Previous Message | KONDO Mitsumasa | 2013-06-21 06:25:36 | Re: [PATCH] add --progress option to pgbench (submission 3) |