1. 29 Oct, 2010 4 commits
    • Tom Lane's avatar
      Oops, missed one fix for EquivalenceClass rearrangement. · 48a1fb23
      Tom Lane authored
      Now that we're expecting a mergeclause's left_ec/right_ec to persist from
      the initial assignments, we can't just blithely zero these out when
      transforming such a clause in adjust_appendrel_attrs.  But really it should
      be okay to keep the parent's values, since a child table's derived Var
      ought to be equivalent to the parent Var for all EquivalenceClass purposes.
      (Indeed, I'm wondering whether we couldn't find a way to dispense with
      add_child_rel_equivalences altogether.  But this is wrong in any case.)
      48a1fb23
    • Tom Lane's avatar
      Avoid creation of useless EquivalenceClasses during planning. · 14231a41
      Tom Lane authored
      Zoltan Boszormenyi exhibited a test case in which planning time was
      dominated by construction of EquivalenceClasses and PathKeys that had no
      actual relevance to the query (and in fact got discarded immediately).
      This happened because we generated PathKeys describing the sort ordering of
      every index on every table in the query, and only after that checked to see
      if the sort ordering was relevant.  The EC/PK construction code is O(N^2)
      in the number of ECs, which is all right for the intended number of such
      objects, but it gets out of hand if there are ECs for lots of irrelevant
      indexes.
      
      To fix, twiddle the handling of mergeclauses a little bit to ensure that
      every interesting EC is created before we begin path generation.  (This
      doesn't cost anything --- in fact I think it's a bit cheaper than before
      --- since we always eventually created those ECs anyway.)  Then, if an
      index column can't be found in any pre-existing EC, we know that that sort
      ordering is irrelevant for the query.  Instead of creating a useless EC,
      we can just not build a pathkey for the index column in the first place.
      The index will still be considered if it's useful for non-order-related
      reasons, but we will think of its output as unsorted.
      14231a41
    • Heikki Linnakangas's avatar
      Give a more specific error message if you try to COMMIT, ROLLBACK or COPY · f184de35
      Heikki Linnakangas authored
      FROM STDIN in PL/pgSQL. We alread did this for dynamic EXECUTE statements,
      ie. "EXECUTE 'COMMIT'", but not otherwise.
      f184de35
    • Andrew Dunstan's avatar
      6c3c7b53
  2. 28 Oct, 2010 9 commits
  3. 27 Oct, 2010 5 commits
  4. 26 Oct, 2010 7 commits
  5. 25 Oct, 2010 7 commits
  6. 24 Oct, 2010 1 commit
  7. 22 Oct, 2010 3 commits
  8. 21 Oct, 2010 2 commits
    • Bruce Momjian's avatar
      71be8db5
    • Tom Lane's avatar
      Improve handling of domains over arrays. · 529cb267
      Tom Lane authored
      This patch eliminates various bizarre behaviors caused by sloppy thinking
      about the difference between a domain type and its underlying array type.
      In particular, the operation of updating one element of such an array
      has to be considered as yielding a value of the underlying array type,
      *not* a value of the domain, because there's no assurance that the
      domain's CHECK constraints are still satisfied.  If we're intending to
      store the result back into a domain column, we have to re-cast to the
      domain type so that constraints are re-checked.
      
      For similar reasons, such a domain can't be blindly matched to an ANYARRAY
      polymorphic parameter, because the polymorphic function is likely to apply
      array-ish operations that could invalidate the domain constraints.  For the
      moment, we just forbid such matching.  We might later wish to insert an
      automatic downcast to the underlying array type, but such a change should
      also change matching of domains to ANYELEMENT for consistency.
      
      To ensure that all such logic is rechecked, this patch removes the original
      hack of setting a domain's pg_type.typelem field to match its base type;
      the typelem will always be zero instead.  In those places where it's really
      okay to look through the domain type with no other logic changes, use the
      newly added get_base_element_type function in place of get_element_type.
      catversion bumped due to change in pg_type contents.
      
      Per bug #5717 from Richard Huxton and subsequent discussion.
      529cb267
  9. 20 Oct, 2010 2 commits