Re: TABLE not synonymous with SELECT * FROM? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TABLE not synonymous with SELECT * FROM?
Date
Msg-id 16231.1384178625@sss.pgh.pa.us
Whole thread Raw
In response to TABLE not synonymous with SELECT * FROM?  ("Colin 't Hart" <colin@sharpheart.org>)
Responses Re: TABLE not synonymous with SELECT * FROM?  ("Colin 't Hart" <colinthart@gmail.com>)
Re: TABLE not synonymous with SELECT * FROM?  ("Colin 't Hart" <colinthart@gmail.com>)
List pgsql-hackers
"Colin 't Hart" <colin@sharpheart.org> writes:
> I would've thought it was implemented as a shortcut for "SELECT *
> FROM" at the parse level (ie encounter "TABLE" and insert "SELECT *
> FROM" into the parse tree and continue), but it seems there is more to
> it.

If you look at the PG grammar you'll see that "TABLE relation_expr"
appears as one variant of simple_select, which means that you can attach
WITH, ORDER BY, FOR UPDATE, or LIMIT to it.  The other things you mention
are only possible in a clause that actually starts with SELECT.  AFAICS,
this comports with the SQL standard's syntax specification (look at the
difference between <query specification> and <query expression>).
The comment for simple_select saith
* Note that sort clauses cannot be included at this level --- SQL requires*        SELECT foo UNION SELECT bar ORDER BY
baz*to be parsed as*        (SELECT foo UNION SELECT bar) ORDER BY baz* not*        SELECT foo UNION (SELECT bar ORDER
BYbaz)* Likewise for WITH, FOR UPDATE and LIMIT.  Therefore, those clauses are* described as part of the
select_no_parensproduction, not simple_select.* This does not limit functionality, because you can reintroduce these*
clausesinside parentheses.
 
        regards, tom lane



pgsql-hackers by date:

Previous
From: Rafael Martinez
Date:
Subject: pg_dump and pg_dumpall in real life
Next
From: Ishaya Bhatt
Date:
Subject: Datatyp of a column