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 26144.1386098826@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
Re: UNNEST with multiple args, and TABLE with multiple funcs
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Tue, Dec 03, 2013 at 10:03:32AM -0500, Stephen Frost wrote:
>> Alright, for my 2c, I like having this syntax include 'TABLE' simply
>> because it's what folks coming from Oracle might be looking for.
>> Following from that, to keep it distinct from the spec's notion of
>> 'TABLE', my preference is 'TABLE FROM'.  I don't particularly like
>> 'TABLE OF', nor do I like the various 'ROWS' suggestions.

> I like having "ROWS" in there somehow, because it denotes the distinction from
> SQL-standard TABLE().  Suppose we were to implement the SQL-standard TABLE(),
> essentially just mapping it to UNNEST().  Then we'd have "TABLE (f())" that
> unpacks the single array returned by f(), and we'd have "TABLE FROM (f())"
> that unpacks the set of rows returned by f().  The word "FROM" alone does not
> indicate that difference the way including "ROWS" does.

Hm ... fair point, except that "ROWS" doesn't seem to suggest the right
thing either, at least not to me.  After further thought I've figured
out what's been grating on me about Noah's suggestions: he suggests that
we're distinguishing "TABLE [FROM ELEMENTS]" from "TABLE FROM ROWS",
but this is backwards.  What UNNEST() really does is take an array,
extract the elements, and make a table of those.  Similarly, what our
feature does is take a set (the result of a set-returning function),
extract the rows, and make a table of those.  So what would seem
appropriate to me is "TABLE [FROM ARRAY]" versus "TABLE FROM SET".
Now I find either of those phrases to be one word too many, but the key
point is that I'd probably prefer something involving SET over something
involving ROWS.  (Both of those are unreserved_keyword, so this doesn't
move the ball at all in terms of finding an unambiguous syntax.)

Another issue is that if you are used to the Oracle syntax, in which an
UNNEST() is presumed, it's not exactly clear that TABLE ROWS, or any other
phrase including TABLE, *doesn't* also imply an UNNEST.  So to me that's
kind of a strike against Stephen's preference --- I'm thinking we might be
better off not using the word TABLE.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Extension Templates S03E11
Next
From: Tom Lane
Date:
Subject: Re: Extension Templates S03E11