pgsql: Allow empty target list in SELECT.
От | Tom Lane |
---|---|
Тема | pgsql: Allow empty target list in SELECT. |
Дата | |
Msg-id | E1Vs0Qu-0004bC-6E@gemulon.postgresql.org обсуждение исходный текст |
Ответы |
Re: pgsql: Allow empty target list in SELECT.
|
Список | pgsql-committers |
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. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/1b4f7f93b4693858cb983af3cd557f6097dab67b Modified Files -------------- doc/src/sgml/ref/select.sgml | 28 +++++++++++++++++++++------- src/backend/parser/analyze.c | 13 +++++++++++++ src/backend/parser/gram.y | 8 ++++++-- src/backend/parser/parse_clause.c | 19 +++++++++++++++++++ src/test/regress/expected/errors.out | 23 ++++++++--------------- src/test/regress/sql/errors.sql | 15 ++++++--------- 6 files changed, 73 insertions(+), 33 deletions(-)
В списке pgsql-committers по дате отправления: