1. 02 Feb, 2007 1 commit
    • Tom Lane's avatar
      Repair failure to check that a table is still compatible with a previously · 5413eef8
      Tom Lane authored
      made query plan.  Use of ALTER COLUMN TYPE creates a hazard for cached
      query plans: they could contain Vars that claim a column has a different
      type than it now has.  Fix this by checking during plan startup that Vars
      at relation scan level match the current relation tuple descriptor.  Since
      at that point we already have at least AccessShareLock, we can be sure the
      column type will not change underneath us later in the query.  However,
      since a backend's locks do not conflict against itself, there is still a
      hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
      while a query is in progress in the current backend.  Seal that hole by
      rejecting ALTER TABLE whenever the target relation is already open in
      the current backend.
      
      This is a significant security hole: not only can one trivially crash the
      backend, but with appropriate misuse of pass-by-reference datatypes it is
      possible to read out arbitrary locations in the server process's memory,
      which could allow retrieving database content the user should not be able
      to see.  Our thanks to Jeff Trout for the initial report.
      
      Security: CVE-2007-0556
      5413eef8
  2. 10 Jan, 2007 1 commit
    • 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
  3. 09 Jan, 2007 1 commit
    • 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
  4. 05 Jan, 2007 1 commit
  5. 04 Oct, 2006 1 commit
  6. 27 Jul, 2006 1 commit
    • Tom Lane's avatar
      Aggregate functions now support multiple input arguments. I also took · 108fe473
      Tom Lane authored
      the opportunity to treat COUNT(*) as a zero-argument aggregate instead
      of the old hack that equated it to COUNT(1); this is materially cleaner
      (no more weird ANYOID cases) and ought to be at least a tiny bit faster.
      Original patch by Sergey Koposov; review, documentation, simple regression
      tests, pg_dump and psql support by moi.
      108fe473
  7. 14 Jul, 2006 1 commit
  8. 13 Jul, 2006 1 commit
  9. 28 Jun, 2006 2 commits
  10. 21 Jun, 2006 1 commit
  11. 04 Apr, 2006 1 commit
    • 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
  12. 05 Mar, 2006 1 commit
  13. 28 Feb, 2006 1 commit
    • Tom Lane's avatar
      Extend the ExecInitNode API so that plan nodes receive a set of flag · 2c0ef977
      Tom Lane authored
      bits indicating which optional capabilities can actually be exercised
      at runtime.  This will allow Sort and Material nodes, and perhaps later
      other nodes, to avoid unnecessary overhead in common cases.
      This commit just adds the infrastructure and arranges to pass the correct
      flag values down to plan nodes; none of the actual optimizations are here
      yet.  I'm committing this separately in case anyone wants to measure the
      added overhead.  (It should be negligible.)
      
      Simon Riggs and Tom Lane
      2c0ef977
  14. 22 Nov, 2005 1 commit
  15. 15 Oct, 2005 1 commit
  16. 28 Jun, 2005 1 commit
    • Tom Lane's avatar
      Replace pg_shadow and pg_group by new role-capable catalogs pg_authid · 7762619e
      Tom Lane authored
      and pg_auth_members.  There are still many loose ends to finish in this
      patch (no documentation, no regression tests, no pg_dump support for
      instance).  But I'm going to commit it now anyway so that Alvaro can
      make some progress on shared dependencies.  The catalog changes should
      be pretty much done.
      7762619e
  17. 06 May, 2005 1 commit
  18. 29 Mar, 2005 1 commit
    • Tom Lane's avatar
      Convert oidvector and int2vector into variable-length arrays. This · 70c9763d
      Tom Lane authored
      change saves a great deal of space in pg_proc and its primary index,
      and it eliminates the former requirement that INDEX_MAX_KEYS and
      FUNC_MAX_ARGS have the same value.  INDEX_MAX_KEYS is still embedded
      in the on-disk representation (because it affects index tuple header
      size), but FUNC_MAX_ARGS is not.  I believe it would now be possible
      to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet.
      There are still a lot of vestigial references to FUNC_MAX_ARGS, which
      I will clean up in a separate pass.  However, getting rid of it
      altogether would require changing the FunctionCallInfoData struct,
      and I'm not sure I want to buy into that.
      70c9763d
  19. 22 Mar, 2005 1 commit
  20. 16 Mar, 2005 1 commit
    • Tom Lane's avatar
      Revise TupleTableSlot code to avoid unnecessary construction and disassembly · f97aebd1
      Tom Lane authored
      of tuples when passing data up through multiple plan nodes.  A slot can now
      hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting
      of Datum/isnull arrays.  Upper plan levels can usually just copy the Datum
      arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr()
      calls to extract the data again.  This work extends Atsushi Ogawa's earlier
      patch, which provided the key idea of adding Datum arrays to TupleTableSlots.
      (I believe however that something like this was foreseen way back in Berkeley
      days --- see the old comment on ExecProject.)  A test case involving many
      levels of join of fairly wide tables (about 80 columns altogether) showed
      about 3x overall speedup, though simple queries will probably not be
      helped very much.
      
      I have also duplicated some code in heaptuple.c in order to provide versions
      of heap_formtuple and friends that use "bool" arrays to indicate null
      attributes, instead of the old convention of "char" arrays containing either
      'n' or ' '.  This provides a better match to the convention used by
      ExecEvalExpr.  While I have not made a concerted effort to get rid of uses
      of the old routines, I think they should be deprecated and eventually removed.
      f97aebd1
  21. 12 Mar, 2005 1 commit
    • Tom Lane's avatar
      Adjust the API for aggregate function calls so that a C-coded function · fa5e4401
      Tom Lane authored
      can tell whether it is being used as an aggregate or not.  This allows
      such a function to avoid re-pallocing a pass-by-reference transition
      value; normally it would be unsafe for a function to scribble on an input,
      but in the aggregate case it's safe to reuse the old transition value.
      Make int8inc() do this.  This gets a useful improvement in the speed of
      COUNT(*), at least on narrow tables (it seems to be swamped by I/O when
      the table rows are wide).  Per a discussion in early December with
      Neil Conway.  I also fixed int_aggregate.c to check this, thereby
      turning it into something approaching a supportable technique instead
      of being a crude hack.
      fa5e4401
  22. 28 Jan, 2005 1 commit
  23. 27 Jan, 2005 1 commit
  24. 31 Dec, 2004 1 commit
    • PostgreSQL Daemon's avatar
      · 2ff50159
      PostgreSQL Daemon authored
      Tag appropriate files for rc3
      
      Also performed an initial run through of upgrading our Copyright date to
      extend to 2005 ... first run here was very simple ... change everything
      where: grep 1996-2004 && the word 'Copyright' ... scanned through the
      generated list with 'less' first, and after, to make sure that I only
      picked up the right entries ...
      2ff50159
  25. 29 Aug, 2004 2 commits
  26. 10 Jul, 2004 1 commit
  27. 06 Jun, 2004 1 commit
    • Tom Lane's avatar
      Infrastructure for I/O of composite types: arrange for the I/O routines · c541bb86
      Tom Lane authored
      of a composite type to get that type's OID as their second parameter,
      in place of typelem which is useless.  The actual changes are mostly
      centralized in getTypeInputInfo and siblings, but I had to fix a few
      places that were fetching pg_type.typelem for themselves instead of
      using the lsyscache.c routines.  Also, I renamed all the related variables
      from 'typelem' to 'typioparam' to discourage people from assuming that
      they necessarily contain array element types.
      c541bb86
  28. 30 May, 2004 1 commit
  29. 26 May, 2004 1 commit
    • Neil Conway's avatar
      Reimplement the linked list data structure used throughout the backend. · d0b4399d
      Neil Conway authored
      In the past, we used a 'Lispy' linked list implementation: a "list" was
      merely a pointer to the head node of the list. The problem with that
      design is that it makes lappend() and length() linear time. This patch
      fixes that problem (and others) by maintaining a count of the list
      length and a pointer to the tail node along with each head node pointer.
      A "list" is now a pointer to a structure containing some meta-data
      about the list; the head and tail pointers in that structure refer
      to ListCell structures that maintain the actual linked list of nodes.
      
      The function names of the list API have also been changed to, I hope,
      be more logically consistent. By default, the old function names are
      still available; they will be disabled-by-default once the rest of
      the tree has been updated to use the new API names.
      d0b4399d
  30. 13 Mar, 2004 1 commit
  31. 03 Feb, 2004 1 commit
    • Tom Lane's avatar
      Rename SortMem and VacuumMem to work_mem and maintenance_work_mem. · 391c3811
      Tom Lane authored
      Make btree index creation and initial validation of foreign-key constraints
      use maintenance_work_mem rather than work_mem as their memory limit.
      Add some code to guc.c to allow these variables to be referenced by their
      old names in SHOW and SET commands, for backwards compatibility.
      391c3811
  32. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  33. 19 Aug, 2003 1 commit
    • Tom Lane's avatar
      Improve dynahash.c's API so that caller can specify the comparison function · 80860c32
      Tom Lane authored
      as well as the hash function (formerly the comparison function was hardwired
      as memcmp()).  This makes it possible to eliminate the special-purpose
      hashtable management code in execGrouping.c in favor of using dynahash to
      manage tuple hashtables; which is a win because dynahash knows how to expand
      a hashtable when the original size estimate was too small, whereas the
      special-purpose code was too stupid to do that.  (See recent gripe from
      Stephan Szabo about poor performance when hash table size estimate is way
      off.)  Free side benefit: when using string_hash, the default comparison
      function is now strncmp() instead of memcmp().  This should eliminate some
      part of the overhead associated with larger NAMEDATALEN values.
      80860c32
  34. 08 Aug, 2003 1 commit
  35. 04 Aug, 2003 2 commits
  36. 01 Aug, 2003 1 commit
  37. 21 Jul, 2003 1 commit