On 15 December 2013 02:23, Tom Lane <[email protected]> wrote:
> 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.
>
This commit introduces another bug:
# create table colours (id serial, name text, visible boolean);
CREATE TABLE
# insert into colours (name, visible) values
('blue',true),('yellow',true),('ultraviolet',false),('green',true),('infrared',false);
INSERT 0 5
# select into colours2 from colours;
SELECT 5
# select * from colours2;
(No rows)
--
Thom
