summaryrefslogtreecommitdiff
path: root/src/backend/parser/analyze.c
diff options
context:
space:
mode:
authorTom Lane2013-12-15 01:23:26 +0000
committerTom Lane2013-12-15 01:23:26 +0000
commit1b4f7f93b4693858cb983af3cd557f6097dab67b (patch)
tree2caa02d898221a2c2c6036284a8973f873f72e33 /src/backend/parser/analyze.c
parentc03ad5602f529787968fa3201b35c119bbc6d782 (diff)
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.
Diffstat (limited to 'src/backend/parser/analyze.c')
-rw-r--r--src/backend/parser/analyze.c13
1 files changed, 13 insertions, 0 deletions
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index a9d1fecff5c..60cce378453 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -2018,6 +2018,19 @@ transformReturningList(ParseState *pstate, List *returningList)
/* transform RETURNING identically to a SELECT targetlist */
rlist = transformTargetList(pstate, returningList, EXPR_KIND_RETURNING);
+ /*
+ * Complain if the nonempty tlist expanded to nothing (which is possible
+ * if it contains only a star-expansion of a zero-column table). If we
+ * allow this, the parsed Query will look like it didn't have RETURNING,
+ * with results that would probably surprise the user.
+ */
+ if (rlist == NIL)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("RETURNING must have at least one column"),
+ parser_errposition(pstate,
+ exprLocation(linitial(returningList)))));
+
/* mark column origins */
markTargetListOrigins(pstate, rlist);