aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
Commit message (Collapse)AuthorAge
* Various fixes in the logic of XML functions:Peter Eisentraut2007-01-25
| | | | | | | | | | | | | | | | - Add new SQL command SET XML OPTION (also available via regular GUC) to control the DOCUMENT vs. CONTENT option in implicit parsing and serialization operations. - Subtle corrections in the handling of the standalone property in xmlroot(). - Allow xmlroot() to work on content fragments. - Subtle corrections in the handling of the version property in xmlconcat(). - Code refactoring for producing XML declarations.
* Add GUC temp_tablespaces to provide a default location for temporaryBruce Momjian2007-01-25
| | | | | | objects. Jaime Casanova
* Prevent WAL logging when COPY is done in the same transation thatBruce Momjian2007-01-25
| | | | | | created it. Simon Riggs
* Relax an Assert() that has been found to be too strict in some situationsTom Lane2007-01-24
| | | | | | | involving unions of types having typmods. Variants of the failure are known to occur in 8.1 and up; not sure if it's possible in 8.0 and 7.4, but since the code exists that far back, I'll just patch 'em all. Per report from Brian Hurt.
* Remove remains of old depend target.Peter Eisentraut2007-01-20
|
* Fix xmlconcat by properly merging the XML declarations. Add aggregatePeter Eisentraut2007-01-20
| | | | function xmlagg.
* Add support for xmlval IS DOCUMENT expression.Peter Eisentraut2007-01-14
|
* Use XML output escaping also in XMLFOREST.Peter Eisentraut2007-01-12
|
* Teach nodeMergejoin how to handle DESC and/or NULLS FIRST sort orders.Tom Lane2007-01-11
| | | | So far only tested by hacking the planner ...
* Use libxml's xmlwriter API for producing XML elements, instead of doingPeter Eisentraut2007-01-10
| | | | | our own printing dance. This does a better job of quoting and escaping the values.
* Change the planner-to-executor API so that the planner tells the executorTom Lane2007-01-10
| | | | | | | | | | | | | | | | 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.
* Enable another five tuple status bits by using the high bits of theBruce Momjian2007-01-09
| | | | | | nattr field, and rename the field. Heikki Linnakangas
* Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LASTTom Lane2007-01-09
| | | | | | | | | | | | 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.
* Some fine-tuning of xmlpi in corner cases:Peter Eisentraut2007-01-07
| | | | | | - correct error codes - do syntax checks in correct order - strip leading spaces of argument
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-05
| | | | back-stamped for this.
* Fix failure due to accessing an already-freed tuple descriptor in a planTom Lane2006-12-26
| | | | | | | | | | | | involving HashAggregate over SubqueryScan (this is the known case, there may well be more). The bug is only latent in releases before 8.2 since they didn't try to access tupletable slots' descriptors during ExecDropTupleTable. The least bogus fix seems to be to make subqueries share the parent query's memory context, so that tupdescs they create will have the same lifespan as those of the parent query. There are comments in the code envisioning going even further by not having a separate child EState at all, but that will require rethinking executor access to range tables, which I don't want to tackle right now. Per bug report from Jean-Pierre Pelletier.
* Repair bug #2839: the various ExecReScan functions need to resetTom Lane2006-12-26
| | | | | | | | | ps_TupFromTlist in plan nodes that make use of it. This was being done correctly in join nodes and Result nodes but not in any relation-scan nodes. Bug would lead to bogus results if a set-returning function appeared in the targetlist of a subquery that could be rescanned after partial execution, for example a subquery within EXISTS(). Bug has been around forever :-( ... surprising it wasn't reported before.
* Repair bug #2836: SPI_execute_plan returned zero if none of the querytreesTom Lane2006-12-26
| | | | | | | | | were marked canSetTag. While it's certainly correct to return the result of the last one that is marked canSetTag, it's less clear what to do when none of them are. Since plpgsql will complain if zero is returned, the 8.2.0 behavior isn't good. I've fixed it to restore the prior behavior of returning the physically last query's result code when there are no canSetTag queries.
* Code review for XML patch. Instill a bit of sanity in the location ofTom Lane2006-12-24
| | | | | | | 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.
* Restructure operator classes to allow improved handling of cross-data-typeTom Lane2006-12-23
| | | | | | | | | | | | | | | | 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.
* Initial SQL/XML support: xml data type and initial set of functions.Peter Eisentraut2006-12-21
|
* Avoid double free of _SPI_current->tuptable. AtEOSubXact_SPI() now tries toTom Lane2006-12-08
| | | | | | | release it in a subtransaction abort, but this neglects possibility that someone outside SPI already did. Fix is for spi.c to forget about a tuptable as soon as it's handed it back to the caller. Per bug #2817 from Michael Andreen.
* Refactor ExecGetJunkAttribute to avoid searching for junk attributesTom Lane2006-12-04
| | | | | | by name on each and every row processed. Profiling suggests this may buy a percent or two for simple UPDATE scenarios, which isn't huge, but when it's so easy to get ...
* Fix LIMIT/OFFSET for null limit values. This worked before 8.2 but was brokenTom Lane2006-12-03
| | | | | | by the change to make limit values int8 instead of int4. (Specifically, you can do DatumGetInt32 safely on a null value, but not DatumGetInt64.) Per bug #2803 from Greg Johnson.
* Prevent intratransaction memory leak when a subtransaction is abortedTom Lane2006-11-21
| | | | | | in the middle of executing a SPI query. This doesn't entirely fix the problem of memory leakage in plpgsql exception handling, but it should get rid of the lion's share of leakage.
* Small message equalization fixPeter Eisentraut2006-11-17
|
* Remove a 15-year old comment questioning behavior that is now well-Neil Conway2006-11-08
| | | | | established: referencing an undefined parameter should result in an error, not NULL.
* Repair bug #2694 concerning an ARRAY[] construct whose inputs are emptyTom Lane2006-11-06
| | | | | | | | | | sub-arrays. Per discussion, if all inputs are empty arrays then result must be an empty array too, whereas a mix of empty and nonempty arrays should (and already did) draw an error. In the back branches, the construct was strict: any NULL input immediately yielded a NULL output; so I left that behavior alone. HEAD was simply ignoring NULL sub-arrays, which doesn't seem very sensible. For lack of a better idea it now treats NULL sub-arrays the same as empty ones.
* Fix mishandling of after-trigger state when a SQL function returns multipleTom Lane2006-10-12
| | | | | | | | | | rows --- if the surrounding query queued any trigger events between the rows, the events would be fired at the wrong time, leading to bizarre behavior. Per report from Merlin Moncure. This is a simple patch that should solve the problem fully in the back branches, but in HEAD we also need to consider the possibility of queries with RETURNING clauses. Will look into a fix for that separately.
* Message style improvementsPeter Eisentraut2006-10-06
|
* pgindent run for 8.2.Bruce Momjian2006-10-04
|
* Fix IS NULL and IS NOT NULL tests on row-valued expressions to conform toTom Lane2006-09-28
| | | | | | | | | | | | 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.
* Clean up logging for extended-query-protocol operations, as per my recentTom Lane2006-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | proposal. Parameter logging works even for binary-format parameters, and logging overhead is avoided when disabled. log_statement = all output for the src/test/examples/testlibpq3.c example now looks like LOG: statement: execute <unnamed>: SELECT * FROM test1 WHERE t = $1 DETAIL: parameters: $1 = 'joe''s place' LOG: statement: execute <unnamed>: SELECT * FROM test1 WHERE i = $1::int4 DETAIL: parameters: $1 = '2' and log_min_duration_statement = 0 results in LOG: duration: 2.431 ms parse <unnamed>: SELECT * FROM test1 WHERE t = $1 LOG: duration: 2.335 ms bind <unnamed> to <unnamed>: SELECT * FROM test1 WHERE t = $1 DETAIL: parameters: $1 = 'joe''s place' LOG: duration: 0.394 ms execute <unnamed>: SELECT * FROM test1 WHERE t = $1 DETAIL: parameters: $1 = 'joe''s place' LOG: duration: 1.251 ms parse <unnamed>: SELECT * FROM test1 WHERE i = $1::int4 LOG: duration: 0.566 ms bind <unnamed> to <unnamed>: SELECT * FROM test1 WHERE i = $1::int4 DETAIL: parameters: $1 = '2' LOG: duration: 0.173 ms execute <unnamed>: SELECT * FROM test1 WHERE i = $1::int4 DETAIL: parameters: $1 = '2' (This example demonstrates the folly of ignoring parse/bind steps for duration logging purposes, BTW.) Along the way, create a less ad-hoc mechanism for determining which commands are logged by log_statement = mod and log_statement = ddl. The former coding was actually missing quite a few things that look like ddl to me, and it did not handle EXECUTE or extended query protocol correctly at all. This commit does not do anything about the question of whether log_duration should be removed or made less redundant with log_min_duration_statement.
* Change processing of extended-Query mode so that an unnamed statementTom Lane2006-09-06
| | | | | | | | that has parameters is always planned afresh for each Bind command, treating the parameter values as constants in the planner. This removes the performance penalty formerly often paid for using out-of-line parameters --- with this definition, the planner can do constant folding, LIKE optimization, etc. After a suggestion by Andrew@supernews.
* Revert FETCH/MOVE int64 patch. Was using incorrect checks forBruce Momjian2006-09-03
| | | | fetch/move in scan.l.
* Change FETCH/MOVE to use int8.Bruce Momjian2006-09-02
| | | | Dhanaraj M
* Now bind displays prepare as detail, and execute displays prepare andBruce Momjian2006-08-29
| | | | | | | | | | optionally bind. I re-added the "statement:" label so people will understand why the line is being printed (it is log_*statement behavior). Use single quotes for bind values, instead of double quotes, and double literal single quotes in bind values (and document that). I also made use of the DETAIL line to have much cleaner output.
* Add new return codes SPI_OK_INSERT_RETURNING etc to the SPI API.Tom Lane2006-08-27
| | | | | | | Fix all the standard PLs to be able to return tuples from FOO_RETURNING statements as well as utility statements that return tuples. Also, fix oversight that SPI_processed wasn't set for a utility statement returning tuples. Per recent discussion.
* Fix oversight in initial implementation of PORTAL_ONE_RETURNING mode: weTom Lane2006-08-14
| | | | | | | | | | cannot assume that there's exactly one Query in the Portal, as we can for ONE_SELECT mode, because non-SELECT queries might have extra queries added during rule rewrites. Fix things up so that we'll use ONE_RETURNING mode when a Portal contains one primary (canSetTag) query and that query has a RETURNING list. This appears to be a second showstopper reason for running the Portal to completion before we start to hand anything back --- we want to be sure that the rule-added queries get run too.
* When executing a list of queries derived from rule expansion,Tom Lane2006-08-14
| | | | | | | | | _SPI_execute_plan's return code should reflect the type of the query that is marked canSetTag, not necessarily the last one in the list. This is arguably a bug fix, but I'm hesitant to back-patch it because it's the sort of subtle change that might break someone's code, and it's best not to do that kind of thing in point releases.
* Tweak SPI_cursor_open to allow INSERT/UPDATE/DELETE RETURNING; this wasTom Lane2006-08-12
| | | | | | | | merely a matter of fixing the error check, since the underlying Portal infrastructure already handles it. This in turn allows these statements to be used in some existing plpgsql and plperl contexts, such as a plpgsql FOR loop. Also, do some marginal code cleanup in places that were being sloppy about distinguishing SELECT from SELECT INTO.
* Add INSERT/UPDATE/DELETE RETURNING, with basic docs and regression tests.Tom Lane2006-08-12
| | | | | | | | 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
* For protocol-level prepare/bind/execute:Bruce Momjian2006-08-08
| | | | | | | | o print user name for all o print portal name if defined for all o print query for all o reduce log_statement header to single keyword o print bind parameters as DETAIL if text mode
* Fix domain_in() bug exhibited by Darcy Buskermolen. The idea of an EStateTom Lane2006-08-04
| | | | | | | | | | | | | that's shorter-lived than the expression state being evaluated in it really doesn't work :-( --- we end up with fn_extra caches getting deleted while still in use. Rather than abandon the notion of caching expression state across domain_in calls altogether, I chose to make domain_in a bit cozier with ExprContext. All we really need for evaluating variable-free expressions is an ExprContext, not an EState, so I invented the notion of a "standalone" ExprContext. domain_in can prevent resource leakages by doing a ReScanExprContext on this rather than having to free it entirely; so we can make the ExprContext have the same lifespan (and particularly the same per_query memory context) as the expression state structs.
* Arrange for ValuesScan to keep per-sublist expression eval state in aTom Lane2006-08-02
| | | | | | | temporary context that can be reset when advancing to the next sublist. This is faster and more thorough at recovering space than the previous method; moreover it will do the right thing if something in the sublist tries to register an expression context callback.
* Add support for multi-row VALUES clauses as part of INSERT statementsJoe Conway2006-08-02
| | | | | | (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.
* Change the relation_open protocol so that we obtain lock on a relationTom Lane2006-07-31
| | | | | | | | | | | | (table or index) before trying to open its relcache entry. This fixes race conditions in which someone else commits a change to the relation's catalog entries while we are in process of doing relcache load. Problems of that ilk have been reported sporadically for years, but it was not really practical to fix until recently --- for instance, the recent addition of WAL-log support for in-place updates helped. Along the way, remove pg_am.amconcurrent: all AMs are now expected to support concurrent update.
* Change the bootstrap sequence so that toast tables for system catalogs areTom Lane2006-07-31
| | | | | | | | | | created in the bootstrap phase proper, rather than added after-the-fact by initdb. This is cleaner than before because it allows us to retire the undocumented ALTER TABLE ... CREATE TOAST TABLE command, but the real reason I'm doing it is so that toast tables of shared catalogs will now have predetermined OIDs. This will allow a reasonably clean solution to the problem of locking tables before we load their relcache entries, to appear in a forthcoming patch.
* Aggregate functions now support multiple input arguments. I also tookTom Lane2006-07-27
| | | | | | | | 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.
* Code review for bigint-LIMIT patch. Fix missed planner dependency,Tom Lane2006-07-26
| | | | | | eliminate unnecessary code, force initdb because stored rules change (limit nodes are now supposed to be int8 not int4 expressions). Update comments and error messages, which still all said 'integer'.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 10:45:57 +0000