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

From Noah Misch
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 20131203042649.GA1163520@tornado.leadboat.com
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs
Re: UNNEST with multiple args, and TABLE with multiple funcs
List pgsql-hackers
On Mon, Dec 02, 2013 at 08:56:03PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > ... I propose merely changing the syntax to "TABLE FOR ROWS (...)".
> 
> 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.
> 
> > ROWS FROM
> 
> This one's a little less awful than the rest.  What about "ROWS OF"?

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.  We
could force that to work.  However, if we ever wish to allow an arbitrary
from_item in the list, it would become ambiguous: is this drawing rows from
"a" or just using an alias with a column list?
 WITH a AS (SELECT oid FROM pg_am ORDER BY 1) SELECT * FROM rows of(a, a);

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

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Status of FDW pushdowns
Next
From: Noah Misch
Date:
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing