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
      11e13185
      Improve ruleutils.c's heuristics for dealing with rangetable aliases. · 11e13185
      Tom Lane authored
      The previous scheme had bugs in some corner cases involving tables that had
      been renamed since a view was made.  This could result in dumped views that
      failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd
      Albin, as well as in some pgsql-hackers discussion back in January.  Also,
      its behavior for printing EXPLAIN plans was sometimes confusing because of
      willingness to use the same alias for multiple RTEs (it was Ashutosh
      Bapat's complaint about that aspect that started the January thread).
      
      To fix, ensure that each RTE in the query has a unique unqualified alias,
      by modifying the alias if necessary (we add "_" and digits as needed to
      create a non-conflicting name).  Then we can just print its variables with
      that alias, avoiding the confusing and bug-prone scheme of sometimes
      schema-qualifying variable names.  In EXPLAIN, it proves to be expedient to
      take the further step of only assigning such aliases to RTEs that are
      actually referenced in the query, since the planner has a habit of
      generating extra RTEs with the same alias in situations such as
      inheritance-tree expansion.
      
      Although this fixes a bug of very long standing, I'm hesitant to back-patch
      such a noticeable behavioral change.  My experiments while creating a
      regression test convinced me that actually incorrect output (as opposed to
      confusing output) occurs only in very narrow cases, which is backed up by
      the lack of previous complaints from the field.  So we may be better off
      living with it in released branches; and in any case it'd be smart to let
      this ripen awhile in HEAD before we consider back-patching it.
      11e13185
      History
      Improve ruleutils.c's heuristics for dealing with rangetable aliases.
      Tom Lane authored
      The previous scheme had bugs in some corner cases involving tables that had
      been renamed since a view was made.  This could result in dumped views that
      failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd
      Albin, as well as in some pgsql-hackers discussion back in January.  Also,
      its behavior for printing EXPLAIN plans was sometimes confusing because of
      willingness to use the same alias for multiple RTEs (it was Ashutosh
      Bapat's complaint about that aspect that started the January thread).
      
      To fix, ensure that each RTE in the query has a unique unqualified alias,
      by modifying the alias if necessary (we add "_" and digits as needed to
      create a non-conflicting name).  Then we can just print its variables with
      that alias, avoiding the confusing and bug-prone scheme of sometimes
      schema-qualifying variable names.  In EXPLAIN, it proves to be expedient to
      take the further step of only assigning such aliases to RTEs that are
      actually referenced in the query, since the planner has a habit of
      generating extra RTEs with the same alias in situations such as
      inheritance-tree expansion.
      
      Although this fixes a bug of very long standing, I'm hesitant to back-patch
      such a noticeable behavioral change.  My experiments while creating a
      regression test convinced me that actually incorrect output (as opposed to
      confusing output) occurs only in very narrow cases, which is backed up by
      the lack of previous complaints from the field.  So we may be better off
      living with it in released branches; and in any case it'd be smart to let
      this ripen awhile in HEAD before we consider back-patching it.