Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. Apr 24, 2010
  4. Feb 26, 2010
  5. 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
  6. 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
  7. Jan 02, 2010
  8. Dec 29, 2009
  9. Aug 10, 2009
  10. Jun 11, 2009
  11. Jan 01, 2009
  12. Sep 28, 2008
  13. 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
  14. 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
  15. 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
  16. 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
  17. Jan 01, 2008
  18. Nov 15, 2007
  19. 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
  20. 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
  21. Apr 02, 2007
  22. Mar 19, 2007
  23. 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
  24. 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
  25. Jan 30, 2007
  26. 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
  27. Jan 21, 2007
  28. Jan 20, 2007
    • Tom Lane's avatar
      Refactor planner's pathkeys data structure to create a separate, explicit · f41803bb
      Tom Lane authored
      representation of equivalence classes of variables.  This is an extensive
      rewrite, but it brings a number of benefits:
      * planner no longer fails in the presence of "incomplete" operator families
      that don't offer operators for every possible combination of datatypes.
      * avoid generating and then discarding redundant equality clauses.
      * remove bogus assumption that derived equalities always use operators
      named "=".
      * mergejoins can work with a variety of sort orders (e.g., descending) now,
      instead of tying each mergejoinable operator to exactly one sort order.
      * better recognition of redundant sort columns.
      * can make use of equalities appearing underneath an outer join.
      f41803bb
  29. Jan 10, 2007
    • Tom Lane's avatar
      Change the planner-to-executor API so that the planner tells the executor · a191a169
      Tom Lane authored
      which comparison operators to use for plan nodes involving tuple comparison
      (Agg, Group, Unique, SetOp).  Formerly the executor looked up the default
      equality operator for the datatype, which was really pretty shaky, since it's
      possible that the data being fed to the node is sorted according to some
      nondefault operator class that could have an incompatible idea of equality.
      The planner knows what it has sorted by and therefore can provide the right
      equality operator to use.  Also, this change moves a couple of catalog lookups
      out of the executor and into the planner, which should help startup time for
      pre-planned queries by some small amount.  Modify the planner to remove some
      other cavalier assumptions about always being able to use the default
      operators.  Also add "nulls first/last" info to the Plan node for a mergejoin
      --- neither the executor nor the planner can cope yet, but at least the API is
      in place.
      a191a169
  30. Jan 09, 2007
    • Tom Lane's avatar
      Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST · 44317582
      Tom Lane authored
      per-column options for btree indexes.  The planner's support for this is still
      pretty rudimentary; it does not yet know how to plan mergejoins with
      nondefault ordering options.  The documentation is pretty rudimentary, too.
      I'll work on improving that stuff later.
      
      Note incompatible change from prior behavior: ORDER BY ... USING will now be
      rejected if the operator is not a less-than or greater-than member of some
      btree opclass.  This prevents less-than-sane behavior if an operator that
      doesn't actually define a proper sort ordering is selected.
      44317582
  31. Jan 05, 2007
  32. Dec 30, 2006
  33. Dec 23, 2006
    • Tom Lane's avatar
      Restructure operator classes to allow improved handling of cross-data-type · a78fcfb5
      Tom Lane authored
      cases.  Operator classes now exist within "operator families".  While most
      families are equivalent to a single class, related classes can be grouped
      into one family to represent the fact that they are semantically compatible.
      Cross-type operators are now naturally adjunct parts of a family, without
      having to wedge them into a particular opclass as we had done originally.
      
      This commit restructures the catalogs and cleans up enough of the fallout so
      that everything still works at least as well as before, but most of the work
      needed to actually improve the planner's behavior will come later.  Also,
      there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
      to create a new family right now is to allow CREATE OPERATOR CLASS to make
      one by default.  I owe some more documentation work, too.  But that can all
      be done in smaller pieces once this infrastructure is in place.
      a78fcfb5
  34. Oct 04, 2006
  35. Sep 28, 2006
    • Tom Lane's avatar
      Fix IS NULL and IS NOT NULL tests on row-valued expressions to conform to · f213131f
      Tom Lane authored
      the SQL spec, viz IS NULL is true if all the row's fields are null, IS NOT
      NULL is true if all the row's fields are not null.  The former coding got
      this right for a limited number of cases with IS NULL (ie, those where it
      could disassemble a ROW constructor at parse time), but was entirely wrong
      for IS NOT NULL.  Per report from Teodor.
      
      I desisted from changing the behavior for arrays, since on closer inspection
      it's not clear that there's any support for that in the SQL spec.  This
      probably needs more consideration.
      f213131f
  36. Aug 16, 2006
  37. Jul 14, 2006
  38. Apr 06, 2006
    • Tom Lane's avatar
      Fix a bunch of problems with domains by making them use special input functions · 7fdb4305
      Tom Lane authored
      that apply the necessary domain constraint checks immediately.  This fixes
      cases where domain constraints went unchecked for statement parameters,
      PL function local variables and results, etc.  We can also eliminate existing
      special cases for domains in places that had gotten it right, eg COPY.
      
      Also, allow domains over domains (base of a domain is another domain type).
      This almost worked before, but was disallowed because the original patch
      hadn't gotten it quite right.
      7fdb4305
  39. Apr 04, 2006
    • Tom Lane's avatar
      Modify all callers of datatype input and receive functions so that if these · 147d4bf3
      Tom Lane authored
      functions are not strict, they will be called (passing a NULL first parameter)
      during any attempt to input a NULL value of their datatype.  Currently, all
      our input functions are strict and so this commit does not change any
      behavior.  However, this will make it possible to build domain input functions
      that centralize checking of domain constraints, thereby closing numerous holes
      in our domain support, as per previous discussion.
      
      While at it, I took the opportunity to introduce convenience functions
      InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O
      functions.  This eliminates a lot of grotty-looking casts, but the main
      motivation is to make it easier to grep for these places if we ever need
      to touch them again.
      147d4bf3
Loading