- 19 2月, 2016 1 次提交
-
-
由 Abhijit Subramanya 提交于
Users should use error log functionality for error handling in external tables and during copy since it is more robust and reliable than the old error table functionality.
-
- 26 1月, 2016 1 次提交
-
-
由 Kuien Liu 提交于
Functions can be declared with parameters with default values or expressions. The default expressions are used as parameter value if the parameter is not explicitly specified in a function call. All parameters after a parameter with default value have to be parameters with default values as well. It allows user to invoke a UDF without setting all the parameters. Two examples to demo its usage: CREATE FUNCTION dfunc1(text DEFAULT 'Hello', text DEFAULT 'World') RETURNS text AS $$ SELECT $1 || ', ' || $2; $$ LANGUAGE SQL; SELECT dfunc1(); -- 'Hello, World' SELECT dfunc1('Hi'); -- 'Hi, World' SELECT dfunc1('Hi', 'Beijing'); -- 'Hi, Beijing' CREATE FUNCTION dfunc2(id int4, t timestamp DEFAULT now()) RETURNS text AS $$ SELECT 'Time for id:' || $1 || ' is ' || $2; $$ LANGUAGE SQL; SELECT dfunc2(24); -- 'Time for id:24 is 2016-01-07 14:38' NOTE: The default change set is ported from from PostgreSQL 8.4, original commits: '517ae403' '455dffbb'
-
- 22 12月, 2015 1 次提交
-
-
由 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
-
- 02 12月, 2015 1 次提交
-
-
由 Gang Xiong 提交于
Alter partitioned table set distributed by will dispatch information from QD to QEs, the information is not correctly coded and decoded on both sides when: 1. reorganize = false. 2. table have index. 3. partition table have "with" option.
-
- 18 11月, 2015 1 次提交
-
-
由 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.
-
- 28 10月, 2015 1 次提交
-
-
- 03 2月, 2007 1 次提交
-
-
由 Peter Eisentraut 提交于
observe the xmloption. Reorganize the representation of the XML option in the parse tree and the API to make it easier to manage and understand. Add regression tests for parsing back XML expressions.
-
- 23 1月, 2007 2 次提交
-
-
由 Tom Lane 提交于
FAMILY; and add FAMILY option to CREATE OPERATOR CLASS to allow adding a class to a pre-existing family. Per previous discussion. Man, what a tedious lot of cutting and pasting ...
-
由 Tom Lane 提交于
which I had removed in the first cut of the EquivalenceClass rewrite to simplify that patch a little. But it's still important --- in a four-way join problem mergejoinscansel() was eating about 40% of the planning time according to gprof. Also, improve the EquivalenceClass code to re-use join RestrictInfos rather than generating fresh ones for each join considered. This saves some memory space but more importantly improves the effectiveness of caching planning info in RestrictInfos.
-
- 21 1月, 2007 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 11 1月, 2007 1 次提交
-
-
由 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.
-
- 09 1月, 2007 1 次提交
-
-
由 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.
-
- 06 1月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
back-stamped for this.
-
- 31 12月, 2006 1 次提交
-
-
由 Tom Lane 提交于
about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
-
- 24 12月, 2006 1 次提交
-
-
由 Tom Lane 提交于
the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
-
- 23 12月, 2006 1 次提交
-
-
由 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.
-
- 22 12月, 2006 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 11 12月, 2006 1 次提交
-
-
由 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 ...
-
- 06 11月, 2006 1 次提交
-
-
由 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.
-
- 14 10月, 2006 1 次提交
-
-
由 Tom Lane 提交于
-
- 04 10月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 31 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
Bernd Helmle
-
- 25 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
blocking concurrent writes to the table. Greg Stark, with a little help from Tom Lane.
-
- 21 8月, 2006 1 次提交
-
-
由 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.
-
- 12 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
plpgsql support to come later. Along the way, convert execMain's SELECT INTO support into a DestReceiver, in order to eliminate some ugly special cases. Jonah Harris and Tom Lane
-
- 10 8月, 2006 1 次提交
-
-
由 Tom Lane 提交于
same data type and same typmod, we show that typmod as the output typmod, rather than generic -1. This responds to several complaints over the past few years about UNIONs unexpectedly dropping length or precision info.
-
- 02 8月, 2006 1 次提交
-
-
由 Joe Conway 提交于
(e.g. "INSERT ... VALUES (...), (...), ...") and elsewhere as allowed by the spec. (e.g. similar to a FROM clause subselect). initdb required. Joe Conway and Tom Lane.
-
- 28 7月, 2006 1 次提交
-
-
由 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.
-
- 14 7月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 04 7月, 2006 1 次提交
-
-
由 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.
-
- 02 7月, 2006 4 次提交
-
-
由 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.
-
由 Bruce Momjian 提交于
ITAGAKI Takahiro
-
由 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
-
由 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.
-
- 27 6月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
Greg Stark
-
- 17 6月, 2006 1 次提交
-
-
由 Andrew Dunstan 提交于
DROP ... IF EXISTS for the following cases: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
-
- 01 5月, 2006 1 次提交
-
-
由 Tom Lane 提交于
support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
-
- 22 4月, 2006 1 次提交
-
-
由 Tom Lane 提交于
not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
-
- 16 4月, 2006 1 次提交
-
-
由 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.
-
- 23 3月, 2006 1 次提交
-
-
由 Tom Lane 提交于
for various mistakes involving INSERT and UPDATE target columns.
-