Skip to content
Snippets Groups Projects
  1. Jul 04, 2011
  2. Jun 03, 2011
    • Tom Lane's avatar
      Fix failure to check whether a rowtype's component types are sortable. · ea8e42f3
      Tom Lane authored
      The existence of a btree opclass accepting composite types caused us to
      assume that every composite type is sortable.  This isn't true of course;
      we need to check if the column types are all sortable.  There was logic
      for this for the case of array comparison (ie, check that the element
      type is sortable), but we missed the point for rowtypes.  Per Teodor's
      report of an ANALYZE failure for an unsortable composite type.
      
      Rather than just add some more ad-hoc logic for this, I moved knowledge of
      the issue into typcache.c.  The typcache will now only report out array_eq,
      record_cmp, and friends as usable operators if the array or composite type
      will work with those functions.
      
      Unfortunately we don't have enough info to do this for anonymous RECORD
      types; in that case, just assume it will work, and take the runtime failure
      as before if it doesn't.
      
      This patch might be a candidate for back-patching at some point, but
      given the lack of complaints from the field, I'd rather just test it in
      HEAD for now.
      
      Note: most of the places touched in this patch will need further work
      when we get around to supporting hashing of record types.
      ea8e42f3
  3. Apr 10, 2011
  4. Mar 26, 2011
    • Tom Lane's avatar
      Clean up a few failures to set collation fields in expression nodes. · b23c9fa9
      Tom Lane authored
      I'm not sure these have any non-cosmetic implications, but I'm not sure
      they don't, either.  In particular, ensure the CaseTestExpr generated
      by transformAssignmentIndirection to represent the base target column
      carries the correct collation, because parse_collate.c won't fix that.
      Tweak lsyscache.c API so that we can get the appropriate collation
      without an extra syscache lookup.
      b23c9fa9
    • Tom Lane's avatar
      Pass collation to makeConst() instead of looking it up internally. · bfa4440c
      Tom Lane authored
      In nearly all cases, the caller already knows the correct collation, and
      in a number of places, the value the caller has handy is more correct than
      the default for the type would be.  (In particular, this patch makes it
      significantly less likely that eval_const_expressions will result in
      changing the exposed collation of an expression.)  So an internal lookup
      is both expensive and wrong.
      bfa4440c
  5. Feb 08, 2011
    • Peter Eisentraut's avatar
      Per-column collation support · 414c5a2e
      Peter Eisentraut authored
      This adds collation support for columns and domains, a COLLATE clause
      to override it per expression, and B-tree index support.
      
      Peter Eisentraut
      reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
      414c5a2e
  6. Jan 01, 2011
  7. Dec 03, 2010
    • Tom Lane's avatar
      Create core infrastructure for KNNGIST. · d583f10b
      Tom Lane authored
      This is a heavily revised version of builtin_knngist_core-0.9.  The
      ordering operators are no longer mixed in with actual quals, which would
      have confused not only humans but significant parts of the planner.
      Instead, ordering operators are carried separately throughout planning and
      execution.
      
      Since the API for ambeginscan and amrescan functions had to be changed
      anyway, this commit takes the opportunity to rationalize that a bit.
      RelationGetIndexScan no longer forces a premature index_rescan call;
      instead, callers of index_beginscan must call index_rescan too.  Aside from
      making the AM-side initialization logic a bit less peculiar, this has the
      advantage that we do not make a useless extra am_rescan call when there are
      runtime key values.  AMs formerly could not assume that the key values
      passed to amrescan were actually valid; now they can.
      
      Teodor Sigaev and Tom Lane
      d583f10b
  8. Nov 24, 2010
    • Tom Lane's avatar
      Create the system catalog infrastructure needed for KNNGIST. · 725d52d0
      Tom Lane authored
      This commit adds columns amoppurpose and amopsortfamily to pg_amop, and
      column amcanorderbyop to pg_am.  For the moment all the entries in
      amcanorderbyop are "false", since the underlying support isn't there yet.
      
      Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with
      [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new
      columns of pg_amop to be populated, and create pg_dump support for dumping
      that information.
      
      I also added some documentation, although it's perhaps a bit premature
      given that the feature doesn't do anything useful yet.
      
      Teodor Sigaev, Robert Haas, Tom Lane
      725d52d0
  9. Oct 31, 2010
    • Tom Lane's avatar
      Provide hashing support for arrays. · 186cbbda
      Tom Lane authored
      The core of this patch is hash_array() and associated typcache
      infrastructure, which works just about exactly like the existing support
      for array comparison.
      
      In addition I did some work to ensure that the planner won't think that an
      array type is hashable unless its element type is hashable, and similarly
      for sorting.  This includes adding a datatype parameter to op_hashjoinable
      and op_mergejoinable, and adding an explicit "hashable" flag to
      SortGroupClause.  The lack of a cross-check on the element type was a
      pre-existing bug in mergejoin support --- but it didn't matter so much
      before, because if you couldn't sort the element type there wasn't any good
      alternative to failing anyhow.  Now that we have the alternative of hashing
      the array type, there are cases where we can avoid a failure by being picky
      at the planner stage, so it's time to be picky.
      
      The issue of exactly how to combine the per-element hash values to produce
      an array hash is still open for discussion, but the rest of this is pretty
      solid, so I'll commit it as-is.
      186cbbda
  10. Oct 21, 2010
    • 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
  11. Sep 20, 2010
  12. Aug 05, 2010
    • Robert Haas's avatar
      Standardize get_whatever_oid functions for object types with · 2a6ef344
      Robert Haas authored
      unqualified names.
      
      - Add a missing_ok parameter to get_tablespace_oid.
      - Avoid duplicating get_tablespace_od guts in objectNamesToOids.
      - Add a missing_ok parameter to get_database_oid.
      - Replace get_roleid and get_role_checked with get_role_oid.
      - Add get_namespace_oid, get_language_oid, get_am_oid.
      - Refactor existing code to use new interfaces.
      
      Thanks to KaiGai Kohei for the review.
      2a6ef344
  13. Jul 10, 2010
    • Tom Lane's avatar
      Avoid an Assert failure in deconstruct_array() by making get_attstatsslot() · 5ce63f48
      Tom Lane authored
      use the actual element type of the array it's disassembling, rather than
      trusting the type OID passed in by its caller.  This is needed because
      sometimes the planner passes in a type OID that's only binary-compatible
      with the target column's type, rather than being an exact match.  Per an
      example from Bernd Helmle.
      
      Possibly we should refactor get_attstatsslot/free_attstatsslot to not expect
      the caller to supply type ID data at all, but for now I'll just do the
      minimum-change fix.
      
      Back-patch to 7.4.  Bernd's test case only crashes back to 8.0, but since
      these subroutines are the same in 7.4, I suspect there may be variant
      cases that would crash 7.4 as well.
      5ce63f48
  14. Apr 24, 2010
  15. Feb 26, 2010
  16. Feb 14, 2010
    • Robert Haas's avatar
      Wrap calls to SearchSysCache and related functions using macros. · e26c539e
      Robert Haas authored
      The purpose of this change is to eliminate the need for every caller
      of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists,
      GetSysCacheOid, and SearchSysCacheList to know the maximum number
      of allowable keys for a syscache entry (currently 4).  This will
      make it far easier to increase the maximum number of keys in a
      future release should we choose to do so, and it makes the code
      shorter, too.
      
      Design and review by Tom Lane.
      e26c539e
  17. Jan 04, 2010
    • Tom Lane's avatar
      When estimating the selectivity of an inequality "column > constant" or · 40608e7f
      Tom Lane authored
      "column < constant", and the comparison value is in the first or last
      histogram bin or outside the histogram entirely, try to fetch the actual
      column min or max value using an index scan (if there is an index on the
      column).  If successful, replace the lower or upper histogram bound with
      that value before carrying on with the estimate.  This limits the
      estimation error caused by moving min/max values when the comparison
      value is close to the min or max.  Per a complaint from Josh Berkus.
      
      It is tempting to consider using this mechanism for mergejoinscansel as well,
      but that would inject index fetches into main-line join estimation not just
      endpoint cases.  I'm refraining from that until we can get a better handle
      on the costs of doing this type of lookup.
      40608e7f
  18. Jan 02, 2010
  19. Dec 29, 2009
  20. Aug 10, 2009
  21. Jun 11, 2009
  22. Jan 01, 2009
  23. Sep 28, 2008
  24. Aug 02, 2008
    • Tom Lane's avatar
      Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT items · 95113047
      Tom Lane authored
      as per my recent proposal:
      
      1. Fold SortClause and GroupClause into a single node type SortGroupClause.
      We were already relying on them to be struct-equivalent, so using two node
      tags wasn't accomplishing much except to get in the way of comparing items
      with equal().
      
      2. Add an "eqop" field to SortGroupClause to carry the associated equality
      operator.  This is cheap for the parser to get at the same time it's looking
      up the sort operator, and storing it eliminates the need for repeated
      not-so-cheap lookups during planning.  In future this will also let us
      represent GROUP/DISTINCT operations on datatypes that have hash opclasses
      but no btree opclasses (ie, they have equality but no natural sort order).
      The previous representation simply didn't work for that, since its only
      indicator of comparison semantics was a sort operator.
      
      3. Add a hasDistinctOn boolean to struct Query to explicitly record whether
      the distinctClause came from DISTINCT or DISTINCT ON.  This allows removing
      some complicated and not 100% bulletproof code that attempted to figure
      that out from the distinctClause alone.
      
      This patch doesn't in itself create any new capability, but it's necessary
      infrastructure for future attempts to use hash-based grouping for DISTINCT
      and UNION/INTERSECT/EXCEPT.
      95113047
  25. Jul 30, 2008
    • Tom Lane's avatar
      Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() · bac3e836
      Tom Lane authored
      with system catalog lookups, as was foreseen to be necessary almost since
      their creation.  Instead put the information into two new pg_type columns,
      typcategory and typispreferred.  Add support for setting these when
      creating a user-defined base type.
      
      The category column is just a "char" (i.e. a poor man's enum), allowing
      a crude form of user extensibility of the category list: just use an
      otherwise-unused character.  This seems sufficient for foreseen uses,
      but we could upgrade to having an actual category catalog someday, if
      there proves to be a huge demand for custom type categories.
      
      In this patch I have attempted to hew exactly to the behavior of the
      previous hardwired logic, except for introducing new type categories for
      arrays, composites, and enums.  In particular the default preferred state
      for user-defined types remains TRUE.  That seems worth revisiting, but it
      should be done as a separate patch from introducing the infrastructure.
      Likewise, any adjustment of the standard set of categories should be done
      separately.
      bac3e836
  26. Apr 13, 2008
    • Tom Lane's avatar
      Since createplan.c no longer cares whether index operators are lossy, it has · 226837e5
      Tom Lane authored
      no particular need to do get_op_opfamily_properties() while building an
      indexscan plan.  Postpone that lookup until executor start.  This simplifies
      createplan.c a lot more than it complicates nodeIndexscan.c, and makes things
      more uniform since we already had to do it that way for RowCompare
      expressions.  Should be a bit faster too, at least for plans that aren't
      re-used many times, since we avoid palloc'ing and perhaps copying the
      intermediate list data structure.
      226837e5
  27. Mar 25, 2008
    • Tom Lane's avatar
      Simplify and standardize conversions between TEXT datums and ordinary C · 220db7cc
      Tom Lane authored
      strings.  This patch introduces four support functions cstring_to_text,
      cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and
      two macros CStringGetTextDatum and TextDatumGetCString.  A number of
      existing macros that provided variants on these themes were removed.
      
      Most of the places that need to make such conversions now require just one
      function or macro call, in place of the multiple notational layers that used
      to be needed.  There are no longer any direct calls of textout or textin,
      and we got most of the places that were using handmade conversions via
      memcpy (there may be a few still lurking, though).
      
      This commit doesn't make any serious effort to eliminate transient memory
      leaks caused by detoasting toasted text objects before they reach
      text_to_cstring.  We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few
      places where it was easy, but much more could be done.
      
      Brendan Jurd and Tom Lane
      220db7cc
  28. Jan 01, 2008
  29. Nov 15, 2007
  30. Oct 13, 2007
    • Tom Lane's avatar
      Fix ALTER COLUMN TYPE to preserve the tablespace and reloptions of indexes · 537e92e4
      Tom Lane authored
      it affects.  The original coding neglected tablespace entirely (causing
      the indexes to move to the database's default tablespace) and for an index
      belonging to a UNIQUE or PRIMARY KEY constraint, it would actually try to
      assign the parent table's reloptions to the index :-(.  Per bug #3672 and
      subsequent investigation.
      
      8.0 and 8.1 did not have reloptions, but the tablespace bug is present.
      537e92e4
  31. May 11, 2007
    • Tom Lane's avatar
      Support arrays of composite types, including the rowtypes of regular tables · bc8036fc
      Tom Lane authored
      and views (but not system catalogs, nor sequences or toast tables).  Get rid
      of the hardwired convention that a type's array type is named exactly "_type",
      instead using a new column pg_type.typarray to provide the linkage.  (It still
      will be named "_type", though, except in odd corner cases such as
      maximum-length type names.)
      
      Along the way, make tracking of owner and schema dependencies for types more
      uniform: a type directly created by the user has these dependencies, while a
      table rowtype or auto-generated array type does not have them, but depends on
      its parent object instead.
      
      David Fetter, Andrew Dunstan, Tom Lane
      bc8036fc
  32. Apr 02, 2007
  33. Mar 19, 2007
  34. Mar 17, 2007
    • Tom Lane's avatar
      Fix up the remaining places where the expression node structure would lose · 0f4ff460
      Tom Lane authored
      available information about the typmod of an expression; namely, Const,
      ArrayRef, ArrayExpr, and EXPR and ARRAY SubLinks.  In the ArrayExpr and
      SubLink cases it wasn't really the data structure's fault, but exprTypmod()
      being lazy.  This seems like a good idea in view of the expected increase in
      typmod usage from Teodor's work to allow user-defined types to have typmods.
      In particular this responds to the concerns we had about eliminating the
      special-purpose hack that exprTypmod() used to have for BPCHAR Consts.
      We can now tell whether or not such a Const has been cast to a specific
      length, and report or display properly if so.
      
      initdb forced due to changes in stored rules.
      0f4ff460
  35. Feb 14, 2007
    • Tom Lane's avatar
      Fix up foreign-key mechanism so that there is a sound semantic basis for the · 7bddca34
      Tom Lane authored
      equality checks it applies, instead of a random dependence on whatever
      operators might be named "=".  The equality operators will now be selected
      from the opfamily of the unique index that the FK constraint depends on to
      enforce uniqueness of the referenced columns; therefore they are certain to be
      consistent with that index's notion of equality.  Among other things this
      should fix the problem noted awhile back that pg_dump may fail for foreign-key
      constraints on user-defined types when the required operators aren't in the
      search path.  This also means that the former warning condition about "foreign
      key constraint will require costly sequential scans" is gone: if the
      comparison condition isn't indexable then we'll reject the constraint
      entirely. All per past discussions.
      
      Along the way, make the RI triggers look into pg_constraint for their
      information, instead of using pg_trigger.tgargs; and get rid of the always
      error-prone fixed-size string buffers in ri_triggers.c in favor of building up
      the RI queries in StringInfo buffers.
      
      initdb forced due to columns added to pg_constraint and pg_trigger.
      7bddca34
  36. Jan 30, 2007
  37. Jan 22, 2007
    • Tom Lane's avatar
      Add COST and ROWS options to CREATE/ALTER FUNCTION, plus underlying pg_proc · 5a7471c3
      Tom Lane authored
      columns procost and prorows, to allow simple user adjustment of the estimated
      cost of a function call, as well as control of the estimated number of rows
      returned by a set-returning function.  We might eventually wish to extend this
      to allow function-specific estimation routines, but there seems to be
      consensus that we should try a simple constant estimate first.  In particular
      this provides a relatively simple way to control the order in which different
      WHERE clauses are applied in a plan node, which is a Good Thing in view of the
      fact that the recent EquivalenceClass planner rewrite made that much less
      predictable than before.
      5a7471c3
  38. Jan 21, 2007
Loading