Re: TABLE not synonymous with SELECT * FROM?
От | Tom Lane |
---|---|
Тема | Re: TABLE not synonymous with SELECT * FROM? |
Дата | |
Msg-id | 16231.1384178625@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | TABLE not synonymous with SELECT * FROM? ("Colin 't Hart" <colin@sharpheart.org>) |
Ответы |
Re: TABLE not synonymous with SELECT * FROM?
Re: TABLE not synonymous with SELECT * FROM? |
Список | 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 по дате отправления: