Re: Review: UNNEST (and other functions) WITH ORDINALITY

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Review: UNNEST (and other functions) WITH ORDINALITY
Дата
Msg-id 20130701010035.GC4365@fetter.org
обсуждение исходный текст
Ответ на Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: Review: UNNEST (and other functions) WITH ORDINALITY  (David Fetter <david@fetter.org>)
Список pgsql-hackers
On Mon, Jun 24, 2013 at 03:04:04PM +0100, Dean Rasheed wrote:
> On 21 June 2013 08:31, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> > On 21 June 2013 08:02, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> >> On 21 June 2013 06:54, David Fetter <david@fetter.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.
> >>
> >
> > Expanding on that, I think it's perfectly acceptable to allow
> > potentially duplicate column names in this context. For the majority
> > of simple queries the user wouldn't have to (and wouldn't feel
> > compelled to) supply aliases. Where there was ambiguity they would be
> > forced to do so, but people are already used to that.
> >
> > If I write a simple query that selects from a single unnest() with or
> > without ordinality, I probably won't want to supply aliases.
> >
> > If I select from 2 unnest()'s *without* ordinality, I already have to
> > provide aliases.
> >
> > If I select from 2 SRF's functions with ordinality, I won't be too
> > surprised if I am also forced to provide aliases.
> >
>
> No one else has expressed an opinion about the naming of the new
> column. All other review comments have been addressed, and the patch
> looks to be in good shape, so I'm marking this as ready for committer.
>
> IMO it's a very useful piece of new functionality. Good job!

Thanks!

Please find attach another rev of the patch which reflects the
de-reserving of OVER.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Department of Redundancy Department: makeNode(FuncCall) division
Следующее
От: ian link
Дата:
Сообщение: Re: Review: query result history in psql