Re: UNNEST with multiple args, and TABLE with multiple funcs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 10523.1386081967@sss.pgh.pa.us
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Noah Misch <noah@leadboat.com>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Mon, Dec 02, 2013 at 08:56:03PM -0500, Tom Lane wrote:
>> Ugh :-(.  Verbose and not exactly intuitive, I think.  I don't like
>> any of the other options you listed much better.  Still, the idea of
>> using more than one word might get us out of the bind that a single
>> word would have to be a fully reserved one.

> I had considered ROWS OF and liked it, but I omitted it from the list on
> account of the shift/reduce conflict from a naturally-written Bison rule.
> Distinguishing it from a list of column aliases takes extra look-ahead.

Hmm, yeah, you're right --- at least one of the first two words needs
to be reserved (not something that can be a ColId, at least), or else
we can't tell them from a table name and alias.  So this approach
doesn't give us all that much extra wiggle room.  We do have a number
of already-fully-reserved prepositions (FOR, FROM, IN, ON, TO) but none
of them seem like great choices.

> ROWS FOR is terse and conflict-free.  "FOR" evokes the resemblance to looping
> over the parenthesized section with the functions acting as generators.

Meh.  I don't find that analogy compelling.

After sleeping on it, your other suggestion of TABLE OF, or possibly
TABLE FROM, is starting to grow on me.

Who else has an opinion?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Recovery bug in GIN, missing full page image
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing