1. 22 12月, 2015 1 次提交
    • Y
      VARIADIC paramters of UDF ported from PostgreSQL. · 4665a8d5
      Yu Yang 提交于
      User could use VARIADIC to specify parameter list when defining UDF
      if they want to use variadic parameters. It is easier for user to write
      only one variadic function instead of same name function with different
      parameters. An example for using variadic:
      create function concat(text, variadic anyarray) returns text as $$
      select array_to_string($2, $1);
      $$ language sql immutable strict;
      
      select concat('%', 1, 2, 3, 4, 5);
      
      NOTE: The variadic change set is ported from upstream of PostgreSQL:
      commit 517ae403
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Thu Dec 18 18:20:35 2008 +0000
      
      Code review for function default parameters patch.  Fix numerous problems as
      per recent discussions.  In passing this also fixes a couple of bugs in
      the previous variadic-parameters patch.
      
      commit 6563e9e2
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Wed Jul 16 16:55:24 2008 +0000
      
      Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
      need to deconstruct proargmodes for each pg_proc entry inspected by
      FuncnameGetCandidates().  Fixes function lookup performance regression
      caused by yesterday's variadic-functions patch.
      
      In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
      in cases where it is not actually used for the particular type of function.
      This should buy back some of the space cost of the extra column.
      
      commit d89737d3
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Wed Jul 16 01:30:23 2008 +0000
      
      Support "variadic" functions, which can accept a variable number of arguments
      so long as all the trailing arguments are of the same (non-array) type.
      The function receives them as a single array argument (which is why they
      have to all be the same type).
      
      It might be useful to extend this facility to aggregates, but this patch
      doesn't do that.
      
      This patch imposes a noticeable slowdown on function lookup --- a follow-on
      patch will fix that by adding a redundant column to pg_proc.
      
      Conflicts:
      	src/backend/gpopt/gpdbwrappers.cpp
      4665a8d5
  2. 02 12月, 2015 1 次提交
  3. 18 11月, 2015 1 次提交
    • H
      Remove back-ported partial FDW support. · 601c58c3
      Heikki Linnakangas 提交于
      It was just syntax and catalogs, you couldn't actually do anything useful
      with it. Remove it, so that we have less code to maintain, until it's time
      to merge this stuff from upstream again when we merge with PostgreSQL 8.4.
      It's probably easier to merge this back at that point than maintain this
      backported version in the meanwhile. Less effort now, until we reach that
      point, and once we get to the point in 8.4 that we merge this in, we'll
      have all the preceding patches applied already, so it should merge quite
      smoothly.
      601c58c3
  4. 28 10月, 2015 1 次提交
  5. 11 1月, 2007 1 次提交
    • T
      Change the planner-to-executor API so that the planner tells the executor · a191a169
      Tom Lane 提交于
      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
  6. 09 1月, 2007 1 次提交
    • T
      Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST · 44317582
      Tom Lane 提交于
      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
  7. 06 1月, 2007 1 次提交
  8. 31 12月, 2006 1 次提交
  9. 24 12月, 2006 1 次提交
  10. 23 12月, 2006 1 次提交
    • T
      Restructure operator classes to allow improved handling of cross-data-type · a78fcfb5
      Tom Lane 提交于
      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
  11. 22 12月, 2006 1 次提交
  12. 11 12月, 2006 1 次提交
    • T
      Add a paramtypmod field to Param nodes. This is dead weight for Params · 9fa12ddd
      Tom Lane 提交于
      representing externally-supplied values, since the APIs that carry such
      values only specify type not typmod.  However, for PARAM_SUBLINK Params
      it is handy to carry the typmod of the sublink's output column.  This
      is a much cleaner solution for the recently reported 'could not find
      pathkey item to sort' and 'failed to find unique expression in subplan
      tlist' bugs than my original 8.2-compatible patch.  Besides, someday we
      might want to support typmods for external parameters ...
      9fa12ddd
  13. 06 11月, 2006 1 次提交
    • T
      Fix recently-understood problems with handling of XID freezing, particularly · 48188e16
      Tom Lane 提交于
      in PITR scenarios.  We now WAL-log the replacement of old XIDs with
      FrozenTransactionId, so that such replacement is guaranteed to propagate to
      PITR slave databases.  Also, rather than relying on hint-bit updates to be
      preserved, pg_clog is not truncated until all instances of an XID are known to
      have been replaced by FrozenTransactionId.  Add new GUC variables and
      pg_autovacuum columns to allow management of the freezing policy, so that
      users can trade off the size of pg_clog against the amount of freezing work
      done.  Revise the already-existing code that forces autovacuum of tables
      approaching the wraparound point to make it more bulletproof; also, revise the
      autovacuum logic so that anti-wraparound vacuuming is done per-table rather
      than per-database.  initdb forced because of changes in pg_class, pg_database,
      and pg_autovacuum catalogs.  Heikki Linnakangas, Simon Riggs, and Tom Lane.
      48188e16
  14. 14 10月, 2006 1 次提交
  15. 04 10月, 2006 1 次提交
  16. 31 8月, 2006 1 次提交
  17. 25 8月, 2006 1 次提交
  18. 21 8月, 2006 1 次提交
    • T
      Fix all known problems with pg_dump's handling of serial sequences · 2b2a5072
      Tom Lane 提交于
      by abandoning the idea that it should say SERIAL in the dump.  Instead,
      dump serial sequences and column defaults just like regular ones.
      Add a new backend command ALTER SEQUENCE OWNED BY to let pg_dump recreate
      the sequence-to-column dependency that was formerly created "behind the
      scenes" by SERIAL.  This restores SERIAL to being truly "just a macro"
      consisting of component operations that can be stated explicitly in SQL.
      Furthermore, the new command allows sequence ownership to be reassigned,
      so that old mistakes can be cleaned up.
      
      Also, downgrade the OWNED-BY dependency from INTERNAL to AUTO, since there
      is no longer any very compelling argument why the sequence couldn't be
      dropped while keeping the column.  (This forces initdb, to be sure the
      right kinds of dependencies are in there.)
      
      Along the way, add checks to prevent ALTER OWNER or SET SCHEMA on an
      owned sequence; you can now only do this indirectly by changing the
      owning table's owner or schema.  This is an oversight in previous
      releases, but probably not worth back-patching.
      2b2a5072
  19. 12 8月, 2006 1 次提交
  20. 10 8月, 2006 1 次提交
  21. 02 8月, 2006 1 次提交
  22. 28 7月, 2006 1 次提交
    • T
      Aggregate functions now support multiple input arguments. I also took · 108fe473
      Tom Lane 提交于
      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
  23. 14 7月, 2006 1 次提交
  24. 04 7月, 2006 1 次提交
    • T
      Code review for FILLFACTOR patch. Change WITH grammar as per earlier · b7b78d24
      Tom Lane 提交于
      discussion (including making def_arg allow reserved words), add missed
      opt_definition for UNIQUE case.  Put the reloptions support code in a less
      random place (I chose to make a new file access/common/reloptions.c).
      Eliminate header inclusion creep.  Make the index options functions safely
      user-callable (seems like client apps might like to be able to test validity
      of options before trying to make an index).  Reduce overhead for normal case
      with no options by allowing rd_options to be NULL.  Fix some unmaintainably
      klugy code, including getting rid of Natts_pg_class_fixed at long last.
      Some stylistic cleanup too, and pay attention to keeping comments in sync
      with code.
      
      Documentation still needs work, though I did fix the omissions in
      catalogs.sgml and indexam.sgml.
      b7b78d24
  25. 02 7月, 2006 4 次提交
    • N
      Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep · 7fb9090e
      Neil Conway 提交于
      the read lock we hold on the table's parent relation until commit.
      Update equalfuncs.c for the new field in AlterTableCmd. Various
      improvements to comments, variable names, and error reporting.
      
      There is room for further improvement here, but this is at least
      a step in the right direction.
      7fb9090e
    • B
      Add FILLFACTOR to CREATE INDEX. · 277807bd
      Bruce Momjian 提交于
      ITAGAKI Takahiro
      277807bd
    • B
      ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) · 8c092781
      Bruce Momjian 提交于
      Open items:
      
      There were a few tangentially related issues that have come up that I think
      are TODOs. I'm likely to tackle one or two of these next so I'm interested in
      hearing feedback on them as well.
      
      . Constraints currently do not know anything about inheritance. Tom suggested
        adding a coninhcount and conislocal like attributes have to track their
        inheritance status.
      
      . Foreign key constraints currently do not get copied to new children (and
        therefore my code doesn't verify them). I don't think it would be hard to
        add them and treat them like CHECK constraints.
      
      . No constraints at all are copied to tables defined with LIKE. That makes it
        hard to use LIKE to define new partitions. The standard defines LIKE and
        specifically says it does not copy constraints. But the standard already has
        an option called INCLUDING DEFAULTS; we could always define a non-standard
        extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to
        request a copy including constraints.
      
      . Personally, I think the whole attislocal thing is bunk. The decision about
        whether to drop a column from children tables or not is something that
        should be up to the user and trying to DWIM based on whether there was ever
        a local definition or the column was acquired purely through inheritance is
        hardly ever going to match up with user expectations.
      
      . And of course there's the whole unique and primary key constraint issue. I
        think to get any traction at all on this you have a prerequisite of a real
        partitioned table implementation where the system knows what the partition
        key is so it can recognize when it's a leading part of an index key.
      
      Greg Stark
      8c092781
    • T
      Revise the planner's handling of "pseudoconstant" WHERE clauses, that is · cffd89ca
      Tom Lane 提交于
      clauses containing no variables and no volatile functions.  Such a clause
      can be used as a one-time qual in a gating Result plan node, to suppress
      plan execution entirely when it is false.  Even when the clause is true,
      putting it in a gating node wins by avoiding repeated evaluation of the
      clause.  In previous PG releases, query_planner() would do this for
      pseudoconstant clauses appearing at the top level of the jointree, but
      there was no ability to generate a gating Result deeper in the plan tree.
      To fix it, get rid of the special case in query_planner(), and instead
      process pseudoconstant clauses through the normal RestrictInfo qual
      distribution mechanism.  When a pseudoconstant clause is found attached to
      a path node in create_plan(), pull it out and generate a gating Result at
      that point.  This requires special-casing pseudoconstants in selectivity
      estimation and cost_qual_eval, but on the whole it's pretty clean.
      It probably even makes the planner a bit faster than before for the normal
      case of no pseudoconstants, since removing pull_constant_clauses saves one
      useless traversal of the qual tree.  Per gripe from Phil Frost.
      cffd89ca
  26. 27 6月, 2006 1 次提交
  27. 17 6月, 2006 1 次提交
    • A
      · bbcd0169
      Andrew Dunstan 提交于
      DROP ... IF EXISTS for the following cases:
        language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
      bbcd0169
  28. 01 5月, 2006 1 次提交
  29. 22 4月, 2006 1 次提交
  30. 16 4月, 2006 1 次提交
    • T
      Support the syntax · 3651a3e6
      Tom Lane 提交于
      	CREATE AGGREGATE aggname (input_type) (parameter_list)
      along with the old syntax where the input type was named in the parameter
      list.  This fits more naturally with the way that the aggregate is identified
      in DROP AGGREGATE and other utility commands; furthermore it has a natural
      extension to handle multiple-input aggregates, where the basetype-parameter
      method would get ugly.  In fact, this commit fixes the grammar and all the
      utility commands to support multiple-input aggregates; but DefineAggregate
      rejects it because the executor isn't fixed yet.
      I didn't do anything about treating agg(*) as a zero-input aggregate instead
      of artificially making it a one-input aggregate, but that should be considered
      in combination with supporting multi-input aggregates.
      3651a3e6
  31. 23 3月, 2006 1 次提交
  32. 16 3月, 2006 1 次提交
    • T
      Clean up representation of function RTEs for functions returning RECORD. · 23160139
      Tom Lane 提交于
      The original coding stored the raw parser output (ColumnDef and TypeName
      nodes) which was ugly, bulky, and wrong because it failed to create any
      dependency on the referenced datatype --- and in fact would not track type
      renamings and suchlike.  Instead store a list of column type OIDs in the
      RTE.
      
      Also fix up general failure of recordDependencyOnExpr to do anything sane
      about recording dependencies on datatypes.  While there are many cases where
      there will be an indirect dependency (eg if an operator returns a datatype,
      the dependency on the operator is enough), we do have to record the datatype
      as a separate dependency in examples like CoerceToDomain.
      
      initdb forced because of change of stored rules.
      23160139
  33. 15 3月, 2006 1 次提交
    • T
      Improve parser so that we can show an error cursor position for errors · 20ab467d
      Tom Lane 提交于
      during parse analysis, not only errors detected in the flex/bison stages.
      This is per my earlier proposal.  This commit includes all the basic
      infrastructure, but locations are only tracked and reported for errors
      involving column references, function calls, and operators.  More could
      be done later but this seems like a good set to start with.  I've also
      moved the ReportSyntaxErrorPosition logic out of psql and into libpq,
      which should make it available to more people --- even within psql this
      is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
      20ab467d
  34. 05 3月, 2006 1 次提交
  35. 03 3月, 2006 1 次提交
  36. 19 2月, 2006 1 次提交
  37. 05 2月, 2006 1 次提交
    • A
      · f8b54fe6
      Andrew Dunstan 提交于
      DROP IF EXISTS for ROLE/USER/GROUP
      f8b54fe6