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

explain.c

Blame
    • Tom Lane's avatar
      2ffa740b
      Fix ruleutils to cope with conflicts from adding/dropping/renaming columns. · 2ffa740b
      Tom Lane authored
      In commit 11e13185, we improved the
      rule/view dumping code so that it would produce valid query representations
      even if some of the tables involved in a query had been renamed since the
      query was parsed.  This patch extends that idea to fix problems that occur
      when individual columns are renamed, or added or dropped.  As before, the
      core of the fix is to assign unique new aliases when a name conflict has
      been created.  This is complicated by the JOIN USING feature, which
      requires the same column alias to be used in both input relations, but we
      can handle that with a sufficiently complex approach to assigning aliases.
      
      A fortiori, this patch takes care of situations where the query didn't have
      unique column names to begin with, such as in a recent complaint from Bryan
      Nuse.  (Because of expansion of "SELECT *", re-parsing a dumped query can
      require column name uniqueness even though the original text did not.)
      2ffa740b
      History
      Fix ruleutils to cope with conflicts from adding/dropping/renaming columns.
      Tom Lane authored
      In commit 11e13185, we improved the
      rule/view dumping code so that it would produce valid query representations
      even if some of the tables involved in a query had been renamed since the
      query was parsed.  This patch extends that idea to fix problems that occur
      when individual columns are renamed, or added or dropped.  As before, the
      core of the fix is to assign unique new aliases when a name conflict has
      been created.  This is complicated by the JOIN USING feature, which
      requires the same column alias to be used in both input relations, but we
      can handle that with a sufficiently complex approach to assigning aliases.
      
      A fortiori, this patch takes care of situations where the query didn't have
      unique column names to begin with, such as in a recent complaint from Bryan
      Nuse.  (Because of expansion of "SELECT *", re-parsing a dumped query can
      require column name uniqueness even though the original text did not.)