]> granicus.if.org Git - postgresql/commit
Allow empty target list in SELECT.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 15 Dec 2013 01:23:26 +0000 (20:23 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 15 Dec 2013 01:23:26 +0000 (20:23 -0500)
commit1b4f7f93b4693858cb983af3cd557f6097dab67b
tree2caa02d898221a2c2c6036284a8973f873f72e33
parentc03ad5602f529787968fa3201b35c119bbc6d782
Allow empty target list in SELECT.

This fixes a problem noted as a followup to bug #8648: if a query has a
semantically-empty target list, e.g. SELECT * FROM zero_column_table,
ruleutils.c will dump it as a syntactically-empty target list, which was
not allowed.  There doesn't seem to be any reliable way to fix this by
hacking ruleutils (note in particular that the originally zero-column table
might since have had columns added to it); and even if we had such a fix,
it would do nothing for existing dump files that might contain bad syntax.
The best bet seems to be to relax the syntactic restriction.

Also, add parse-analysis errors for SELECT DISTINCT with no columns (after
*-expansion) and RETURNING with no columns.  These cases previously
produced unexpected behavior because the parsed Query looked like it had
no DISTINCT or RETURNING clause, respectively.  If anyone ever offers
a plausible use-case for this, we could work a bit harder on making the
situation distinguishable.

Arguably this is a bug fix that should be back-patched, but I'm worried
that there may be client apps or PLs that expect "SELECT ;" to throw a
syntax error.  The issue doesn't seem important enough to risk changing
behavior in minor releases.
doc/src/sgml/ref/select.sgml
src/backend/parser/analyze.c
src/backend/parser/gram.y
src/backend/parser/parse_clause.c
src/test/regress/expected/errors.out
src/test/regress/sql/errors.sql