diff options
author | Tom Lane | 2013-12-15 01:23:26 +0000 |
---|---|---|
committer | Tom Lane | 2013-12-15 01:23:26 +0000 |
commit | 1b4f7f93b4693858cb983af3cd557f6097dab67b (patch) | |
tree | 2caa02d898221a2c2c6036284a8973f873f72e33 | |
parent | c03ad5602f529787968fa3201b35c119bbc6d782 (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.
-rw-r--r-- | doc/src/sgml/ref/select.sgml | 28 | ||||
-rw-r--r-- | src/backend/parser/analyze.c | 13 | ||||
-rw-r--r-- | src/backend/parser/gram.y | 8 | ||||
-rw-r--r-- | src/backend/parser/parse_clause.c | 19 | ||||
-rw-r--r-- | src/test/regress/expected/errors.out | 23 | ||||
-rw-r--r-- | src/test/regress/sql/errors.sql | 15 |
6 files changed, 73 insertions, 33 deletions
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index d6a17cc7a4..f9f83f34f7 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -34,7 +34,7 @@ PostgreSQL documentation <synopsis> [ WITH [ RECURSIVE ] <replaceable class="parameter">with_query</replaceable> [, ...] ] SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replaceable> [, ...] ) ] ] - * | <replaceable class="parameter">expression</replaceable> [ [ AS ] <replaceable class="parameter">output_name</replaceable> ] [, ...] + [ * | <replaceable class="parameter">expression</replaceable> [ [ AS ] <replaceable class="parameter">output_name</replaceable> ] [, ...] ] [ FROM <replaceable class="parameter">from_item</replaceable> [, ...] ] [ WHERE <replaceable class="parameter">condition</replaceable> ] [ GROUP BY <replaceable class="parameter">expression</replaceable> [, ...] ] @@ -1740,7 +1740,8 @@ SELECT 2+2; following query is invalid: <programlisting> SELECT distributors.* WHERE distributors.name = 'Westward'; -</programlisting><productname>PostgreSQL</productname> releases prior to +</programlisting> + <productname>PostgreSQL</productname> releases prior to 8.1 would accept queries of this form, and add an implicit entry to the query's <literal>FROM</literal> clause for each table referenced by the query. This is no longer allowed. @@ -1748,6 +1749,19 @@ SELECT distributors.* WHERE distributors.name = 'Westward'; </refsect2> <refsect2> + <title>Empty <literal>SELECT</literal> Lists</title> + + <para> + The list of output expressions after <literal>SELECT</literal> can be + empty, producing a zero-column result table. + This is not valid syntax according to the SQL standard. + <productname>PostgreSQL</productname> allows it to be consistent with + allowing zero-column tables. + However, an empty list is not allowed when <literal>DISTINCT</> is used. + </para> + </refsect2> + + <refsect2> <title>Omitting the <literal>AS</literal> Key Word</title> <para> @@ -1809,10 +1823,6 @@ SELECT distributors.* WHERE distributors.name = 'Westward'; <productname>PostgreSQL</productname> treats <literal>UNNEST()</> the same as other set-returning functions. </para> - - <para> - <literal>ROWS FROM( ... )</> is an extension of the SQL standard. - </para> </refsect2> <refsect2> @@ -1910,9 +1920,13 @@ SELECT distributors.* WHERE distributors.name = 'Westward'; <title>Nonstandard Clauses</title> <para> - The clause <literal>DISTINCT ON</literal> is not defined in the + <literal>DISTINCT ON ( ... )</literal> is an extension of the SQL standard. </para> + + <para> + <literal>ROWS FROM( ... )</> is an extension of the SQL standard. + </para> </refsect2> </refsect1> </refentry> diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index a9d1fecff5..60cce37845 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); diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y index 8fced4427b..f9d45777ca 100644 --- a/src/backend/parser/gram.y +++ b/src/backend/parser/gram.y @@ -334,7 +334,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query); name_list from_clause from_list opt_array_bounds qualified_name_list any_name any_name_list any_operator expr_list attrs - target_list insert_column_list set_target_list + target_list opt_target_list insert_column_list set_target_list set_clause_list set_clause multiple_set_clause ctext_expr_list ctext_row def_list indirection opt_indirection reloption_list group_clause TriggerFuncArgs select_limit @@ -9259,7 +9259,7 @@ select_clause: * However, this is not checked by the grammar; parse analysis must check it. */ simple_select: - SELECT opt_distinct target_list + SELECT opt_distinct opt_target_list into_clause from_clause where_clause group_clause having_clause window_clause { @@ -12215,6 +12215,10 @@ ctext_row: '(' ctext_expr_list ')' { $$ = $2; } * *****************************************************************************/ +opt_target_list: target_list { $$ = $1; } + | /* EMPTY */ { $$ = NIL; } + ; + target_list: target_el { $$ = list_make1($1); } | target_list ',' target_el { $$ = lappend($1, $3); } diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c index 939fa834e0..87b0c8fd41 100644 --- a/src/backend/parser/parse_clause.c +++ b/src/backend/parser/parse_clause.c @@ -2011,6 +2011,20 @@ transformDistinctClause(ParseState *pstate, true); } + /* + * Complain if we found nothing to make DISTINCT. Returning an empty list + * would cause the parsed Query to look like it didn't have DISTINCT, with + * results that would probably surprise the user. Note: this case is + * presently impossible for aggregates because of grammar restrictions, + * but we check anyway. + */ + if (result == NIL) + ereport(ERROR, + (errcode(ERRCODE_SYNTAX_ERROR), + is_agg ? + errmsg("an aggregate with DISTINCT must have at least one argument") : + errmsg("SELECT DISTINCT must have at least one column"))); + return result; } @@ -2115,6 +2129,11 @@ transformDistinctOnClause(ParseState *pstate, List *distinctlist, true); } + /* + * An empty result list is impossible here because of grammar restrictions. + */ + Assert(result != NIL); + return result; } diff --git a/src/test/regress/expected/errors.out b/src/test/regress/expected/errors.out index 4061512977..5f8868da26 100644 --- a/src/test/regress/expected/errors.out +++ b/src/test/regress/expected/errors.out @@ -15,26 +15,24 @@ select 1; -- -- -- SELECT --- missing relation name +-- this used to be a syntax error, but now we allow an empty target list select; -ERROR: syntax error at or near ";" -LINE 1: select; - ^ +-- +(1 row) + -- no such relation select * from nonesuch; ERROR: relation "nonesuch" does not exist LINE 1: select * from nonesuch; ^ --- missing target list -select from pg_database; -ERROR: syntax error at or near "from" -LINE 1: select from pg_database; - ^ -- bad name in target list select nonesuch from pg_database; ERROR: column "nonesuch" does not exist LINE 1: select nonesuch from pg_database; ^ +-- empty distinct list isn't OK +select distinct from pg_database; +ERROR: SELECT DISTINCT must have at least one column -- bad attribute name on lhs of operator select * from pg_database where nonesuch = pg_database.datname; ERROR: column "nonesuch" does not exist @@ -45,12 +43,7 @@ select * from pg_database where pg_database.datname = nonesuch; ERROR: column "nonesuch" does not exist LINE 1: ...ect * from pg_database where pg_database.datname = nonesuch; ^ --- bad select distinct on syntax, distinct attribute missing -select distinct on (foobar) from pg_database; -ERROR: syntax error at or near "from" -LINE 1: select distinct on (foobar) from pg_database; - ^ --- bad select distinct on syntax, distinct attribute not in target list +-- bad attribute name in select distinct on select distinct on (foobar) * from pg_database; ERROR: column "foobar" does not exist LINE 1: select distinct on (foobar) * from pg_database; diff --git a/src/test/regress/sql/errors.sql b/src/test/regress/sql/errors.sql index 2ee707c5c7..cd370b4781 100644 --- a/src/test/regress/sql/errors.sql +++ b/src/test/regress/sql/errors.sql @@ -16,28 +16,25 @@ select 1; -- -- SELECT --- missing relation name +-- this used to be a syntax error, but now we allow an empty target list select; -- no such relation select * from nonesuch; --- missing target list -select from pg_database; -- bad name in target list select nonesuch from pg_database; + +-- empty distinct list isn't OK +select distinct from pg_database; + -- bad attribute name on lhs of operator select * from pg_database where nonesuch = pg_database.datname; -- bad attribute name on rhs of operator select * from pg_database where pg_database.datname = nonesuch; - --- bad select distinct on syntax, distinct attribute missing -select distinct on (foobar) from pg_database; - - --- bad select distinct on syntax, distinct attribute not in target list +-- bad attribute name in select distinct on select distinct on (foobar) * from pg_database; |