From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Colin 't Hart" <colin(at)sharpheart(dot)org> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TABLE not synonymous with SELECT * FROM? |
Date: | 2013-11-11 14:03:45 |
Message-ID: | 16231.1384178625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Colin 't Hart" <colin(at)sharpheart(dot)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 BY baz)
* Likewise for WITH, FOR UPDATE and LIMIT. Therefore, those clauses are
* described as part of the select_no_parens production, not simple_select.
* This does not limit functionality, because you can reintroduce these
* clauses inside parentheses.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ishaya Bhatt | 2013-11-11 14:11:28 | Datatyp of a column |
Previous Message | Rafael Martinez | 2013-11-11 13:59:10 | pg_dump and pg_dumpall in real life |