1. 16 Oct, 2008 1 commit
    • Tom Lane's avatar
      Fix SPI_getvalue and SPI_getbinval to range-check the given attribute number · bcf188a2
      Tom Lane authored
      according to the TupleDesc's natts, not the number of physical columns in the
      tuple.  The previous coding would do the wrong thing in cases where natts is
      different from the tuple's column count: either incorrectly report error when
      it should just treat the column as null, or actually crash due to indexing off
      the end of the TupleDesc's attribute array.  (The second case is probably not
      possible in modern PG versions, due to more careful handling of inheritance
      cases than we once had.  But it's still a clear lack of robustness here.)
      
      The incorrect error indication is ignored by all callers within the core PG
      distribution, so this bug has no symptoms visible within the core code, but
      it might well be an issue for add-on packages.  So patch all the way back.
      bcf188a2
  2. 14 Oct, 2008 10 commits
  3. 13 Oct, 2008 4 commits
  4. 11 Oct, 2008 1 commit
  5. 10 Oct, 2008 4 commits
  6. 09 Oct, 2008 8 commits
  7. 08 Oct, 2008 1 commit
  8. 07 Oct, 2008 8 commits
  9. 06 Oct, 2008 3 commits
    • Tom Lane's avatar
      Fix up ruleutils.c for CTE features. The main problem was that · 742fd06d
      Tom Lane authored
      get_name_for_var_field didn't have enough context to interpret a reference to
      a CTE query's output.  Fixing this requires separate hacks for the regular
      deparse case (pg_get_ruledef) and for the EXPLAIN case, since the available
      context information is quite different.  It's pretty nearly parallel to the
      existing code for SUBQUERY RTEs, though.  Also, add code to make sure we
      qualify a relation name that matches a CTE name; else the CTE will mistakenly
      capture the reference when reloading the rule.
      
      In passing, fix a pre-existing problem with get_name_for_var_field not working
      on variables in targetlists of SubqueryScan plan nodes.  Although latent all
      along, this wasn't a problem until we made EXPLAIN VERBOSE try to print
      targetlists.  To do this, refactor the deparse_context_for_plan API so that
      the special case for SubqueryScan is all on ruleutils.c's side.
      742fd06d
    • Tom Lane's avatar
      When expanding a whole-row Var into a RowExpr during ResolveNew(), attach · bf461538
      Tom Lane authored
      the column alias names of the RTE referenced by the Var to the RowExpr.
      This is needed to allow ruleutils.c to correctly deparse FieldSelect nodes
      referencing such a construct.  Per my recent bug report.
      
      Adding a field to RowExpr forces initdb (because of stored rules changes)
      so this solution is not back-patchable; which is unfortunate because 8.2
      and 8.3 have this issue.  But it only affects EXPLAIN for some pretty odd
      corner cases, so we can probably live without a solution for the back
      branches.
      bf461538
    • Tom Lane's avatar
      Fix GetCTEForRTE() to deal with the possibility that the RTE it's given came · e64bb65a
      Tom Lane authored
      from a query level above the current ParseState.
      e64bb65a