Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

parse_clause.c

  • Tom Lane's avatar
    1b4f7f93
    Allow empty target list in SELECT. · 1b4f7f93
    Tom Lane authored
    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.
    1b4f7f93
    History
    Allow empty target list in SELECT.
    Tom Lane authored
    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.