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_target.c

Blame
    • Tom Lane's avatar
      a7cd853b
      Change post-rewriter representation of dropped columns in joinaliasvars. · a7cd853b
      Tom Lane authored
      It's possible to drop a column from an input table of a JOIN clause in a
      view, if that column is nowhere actually referenced in the view.  But it
      will still be there in the JOIN clause's joinaliasvars list.  We used to
      replace such entries with NULL Const nodes, which is handy for generation
      of RowExpr expansion of a whole-row reference to the view.  The trouble
      with that is that it can't be distinguished from the situation after
      subquery pull-up of a constant subquery output expression below the JOIN.
      Instead, replace such joinaliasvars with null pointers (empty expression
      trees), which can't be confused with pulled-up expressions.  expandRTE()
      still emits the old convention, though, for convenience of RowExpr
      generation and to reduce the risk of breaking extension code.
      
      In HEAD and 9.3, this patch also fixes a problem with some new code in
      ruleutils.c that was failing to cope with implicitly-casted joinaliasvars
      entries, as per recent report from Feike Steenbergen.  That oversight was
      because of an inadequate description of the data structure in parsenodes.h,
      which I've now corrected.  There were some pre-existing oversights of the
      same ilk elsewhere, which I believe are now all fixed.
      a7cd853b
      History
      Change post-rewriter representation of dropped columns in joinaliasvars.
      Tom Lane authored
      It's possible to drop a column from an input table of a JOIN clause in a
      view, if that column is nowhere actually referenced in the view.  But it
      will still be there in the JOIN clause's joinaliasvars list.  We used to
      replace such entries with NULL Const nodes, which is handy for generation
      of RowExpr expansion of a whole-row reference to the view.  The trouble
      with that is that it can't be distinguished from the situation after
      subquery pull-up of a constant subquery output expression below the JOIN.
      Instead, replace such joinaliasvars with null pointers (empty expression
      trees), which can't be confused with pulled-up expressions.  expandRTE()
      still emits the old convention, though, for convenience of RowExpr
      generation and to reduce the risk of breaking extension code.
      
      In HEAD and 9.3, this patch also fixes a problem with some new code in
      ruleutils.c that was failing to cope with implicitly-casted joinaliasvars
      entries, as per recent report from Feike Steenbergen.  That oversight was
      because of an inadequate description of the data structure in parsenodes.h,
      which I've now corrected.  There were some pre-existing oversights of the
      same ilk elsewhere, which I believe are now all fixed.