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.

1 files changed, 21 insertions, 7 deletions

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index d6a17cc7a44..f9f83f34f70 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>