aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/spi.c
Commit message (Collapse)AuthorAge
...
* _SPI_execute_plan failed to return result tuple table to caller inTom Lane2005-10-01
| | | | | | | | | the ProcessUtility case, resulting in an intratransaction memory leak if a utility command actually did return any tuples, as reported by Dmitry Karasik. Fix this and also make the behavior more consistent for cases involving nested SPI operations and multiple query trees, by ensuring that we store the state locally until it is ready to be returned to the caller.
* Make SPI set SPI_processed for CREATE TABLE AS / SELECT INTO commands;Tom Lane2005-06-09
| | | | | | this in turn causes CREATE TABLE AS in plpgsql to set ROW_COUNT. This is how it behaved before 7.4; I had unintentionally changed the behavior in a bit of sloppy micro-optimization.
* For some reason access/tupmacs.h has been #including utils/memutils.h,Tom Lane2005-05-06
| | | | | | | which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
* Change SPI functions to use a `long' when specifying the number of tuplesNeil Conway2005-05-02
| | | | | | | | to produce when running the executor. This is consistent with the internal executor APIs (such as ExecutorRun), which also use a long for this purpose. It also allows FETCH_ALL to be passed -- since FETCH_ALL is defined as LONG_MAX, this wouldn't have worked on platforms where int and long are of different sizes. Per report from Tzahi Fadida.
* Change CREATE TYPE to require datatype output and send functions to haveTom Lane2005-05-01
| | | | | | | only one argument. (Per recent discussion, the option to accept multiple arguments is pretty useless for user-defined types, and would be a likely source of security holes if it was used.) Simplify call sites of output/send functions to not bother passing more than one argument.
* Add SPI_getnspname(), including documentation.Neil Conway2005-03-29
|
* Improve EXPLAIN ANALYZE to show the time spent in each trigger whenTom Lane2005-03-25
| | | | | | | | executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
* Revise TupleTableSlot code to avoid unnecessary construction and disassemblyTom Lane2005-03-16
| | | | | | | | | | | | | | | | | | | | | 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.
* Fix SPI cursor support to allow scanning the results of utility commandsTom Lane2005-02-10
| | | | | | that return tuples (such as EXPLAIN). Per gripe from Michael Fuhr. Side effect: fix an old bug that unintentionally disabled backward scans for all SPI-created cursors.
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-31
| | | | | | | | 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 ...
* Rethink plpgsql's way of handling SPI execution during an exception block.Tom Lane2004-11-16
| | | | | | | | | We don't really want to start a new SPI connection, just keep using the old one; otherwise we have memory management problems as illustrated by John Kennedy's bug report of today. This requires a bit of a hack to ensure the SPI stack state is properly restored, but then again what we were doing before was a hack too, strictly speaking. Add a regression test to cover this case.
* More minor cosmetic improvements:Neil Conway2004-10-13
| | | | | | | | | | - remove another senseless "extern" keyword that was applied to a function definition - change a foo more function signatures from "some_type foo()" to "some_type foo(void)" - rewrite another K&R style function definition - make the type of the "action" function pointer in the KeyWord struct in src/backend/utils/adt/formatting.c more precise
* Message style revisionsPeter Eisentraut2004-10-12
|
* Add some marginal tweaks to eliminate memory leakages associated withTom Lane2004-09-16
| | | | | subtransactions. Trivial subxacts (such as a plpgsql exception block containing no database access) now demonstrably leak zero bytes.
* Restructure subtransaction handling to reduce resource consumption,Tom Lane2004-09-16
| | | | | | | | | | | | | | | | | as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
* Redesign query-snapshot timing so that volatile functions in READ COMMITTEDTom Lane2004-09-13
| | | | | | | | | | | | | mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
* Fire non-deferred AFTER triggers immediately upon query completion,Tom Lane2004-09-10
| | | | | | | | | | | | | rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
* Pgindent run for 8.0.Bruce Momjian2004-08-29
|
* Update copyright to 2004.Bruce Momjian2004-08-29
|
* Allow DECLARE CURSOR to take parameters from the portal in which it isTom Lane2004-08-02
| | | | | | | | | | executed. Previously, the DECLARE would succeed but subsequent FETCHes would fail since the parameter values supplied to DECLARE were not propagated to the portal created for the cursor. In support of this, add type Oids to ParamListInfo entries, which seems like a good idea anyway since code that extracts a value can double-check that it got the type of value it was expecting. Oliver Jowett, with minor editorialization by Tom Lane.
* Be more consistent about reporting SPI errors in the various PLs.Tom Lane2004-07-31
| | | | | | Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
* Replace nested-BEGIN syntax for subtransactions with spec-compliantTom Lane2004-07-27
| | | | | | | SAVEPOINT/RELEASE/ROLLBACK-TO syntax. (Alvaro) Cause COMMIT of a failed transaction to report ROLLBACK instead of COMMIT in its command tag. (Tom) Fix a few loose ends in the nested-transactions stuff.
* More paranoia in AtEOSubXact_SPI: don't assume we can safely use SPI_finishTom Lane2004-07-01
| | | | | | | for cleaning up. It seems possible that the memory contexts SPI_finish would try to touch are already gone; and there's no need for SPI itself to delete them, since the containing contexts will surely be going away anyway at transaction end.
* Nested transactions. There is still much left to do, especially on theTom Lane2004-07-01
| | | | | | | performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
* When using extended-query protocol, postpone planning of unnamed statementsTom Lane2004-06-11
| | | | | | | | | | | | | | | | | | | until Bind is received, so that actual parameter values are visible to the planner. Make use of the parameter values for estimation purposes (but don't fold them into the actual plan). This buys back most of the potential loss of plan quality that ensues from using out-of-line parameters instead of putting literal values right into the query text. This patch creates a notion of constant-folding expressions 'for estimation purposes only', in which case we can be more aggressive than the normal eval_const_expressions() logic can be. Right now the only difference in behavior is inserting bound values for Params, but it will be interesting to look at other possibilities. One that we've seen come up repeatedly is reducing now() and related functions to current values, so that queries like ... WHERE timestampcol > now() - '1 day' have some chance of being planned effectively. Oliver Jowett, with some kibitzing from Tom Lane.
* Infrastructure for I/O of composite types: arrange for the I/O routinesTom Lane2004-06-06
| | | | | | | | | | 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.
* Resurrect heap_deformtuple(), this time implemented as a singly nestedTom Lane2004-06-04
| | | | | | | | | | loop over the fields instead of a loop around heap_getattr. This is considerably faster (O(N) instead of O(N^2)) when there are nulls or varlena fields, since those prevent use of attcacheoff. Replace loops over heap_getattr with heap_deformtuple in situations where all or most of the fields have to be fetched, such as printtup and tuptoaster. Profiling done more than a year ago shows that this should be a nice win for situations involving many-column tables.
* Use the new List API function names throughout the backend, and disable theNeil Conway2004-05-30
| | | | | list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
* Reimplement the linked list data structure used throughout the backend.Neil Conway2004-05-26
| | | | | | | | | | | | | | | | 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.
* Replace TupleTableSlot convention for whole-row variables and functionTom Lane2004-04-01
| | | | | | | | results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
* Revise syntax-error reporting behavior to give pleasant results forTom Lane2004-03-21
| | | | | errors in internally-generated queries, such as those submitted by plpgsql functions. Per recent discussions with Fabien Coelho.
* Document SPI_push() and SPI_pop().Bruce Momjian2004-03-17
|
* Add new SPI functions for use by PL/Java:Bruce Momjian2004-03-05
| | | | | | | | +extern Oid SPI_getargtypeid(void *plan, int argIndex); +extern int SPI_getargcount(void *plan); +extern bool SPI_is_cursor_plan(void *plan); Thomas Hallgren
* Add a warning to AtEOXact_SPI() to catch cases where the currentJoe Conway2003-12-02
| | | | | | transaction has been committed without SPI_finish() being called first. Per recent discussion here: http://archives.postgresql.org/pgsql-patches/2003-11/msg00286.php
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-29
|
* Repair RI trigger visibility problems (this time for sure ;-)) per recentTom Lane2003-10-01
| | | | | | | discussion on pgsql-hackers: in READ COMMITTED mode we just have to force a QuerySnapshot update in the trigger, but in SERIALIZABLE mode we have to run the scan under a current snapshot and then complain if any rows would be updated/deleted that are not visible in the transaction snapshot.
* Get rid of ReferentialIntegritySnapshotOverride by extending Executor APITom Lane2003-09-25
| | | | | | to allow es_snapshot to be set to SnapshotNow rather than a query snapshot. This solves a bug reported by Wade Klaver, wherein triggers fired as a result of RI cascade updates could misbehave.
* _SPI_cursor_operation forgot to check for failure return fromTom Lane2003-09-23
| | | | _SPI_begin_call. Per gripe from Tomasz Myrta.
* Since SPI_modifytuple's natts argument is the number of attributes to beTom Lane2003-09-16
| | | | changed, it should allow a zero value (implying no changes to make).
* Another pgindent run with updated typedefs.Bruce Momjian2003-08-08
|
* Fix nasty little order-of-operations bug in _SPI_cursor_operation.Tom Lane2003-08-08
| | | | Per report from Mendola Gaetano.
* Update copyrights to 2003.Bruce Momjian2003-08-04
|
* pgindent run.Bruce Momjian2003-08-04
|
* Error message editing in backend/executor.Tom Lane2003-07-21
|
* Implement new-protocol binary I/O support in DataRow, Bind, and FunctionCallTom Lane2003-05-09
| | | | | messages. Binary I/O is now up and working, but only for a small set of datatypes (integers, text, bytea).
* Update 3.0 protocol support to match recent agreements about how toTom Lane2003-05-08
| | | | | | | handle multiple 'formats' for data I/O. Restructure CommandDest and DestReceiver stuff one more time (it's finally starting to look a bit clean though). Code now matches latest 3.0 protocol document as far as message formats go --- but there is no support for binary I/O yet.
* Restructure command destination handling so that we pass aroundTom Lane2003-05-06
| | | | | | | | | | | | | | DestReceiver pointers instead of just CommandDest values. The DestReceiver is made at the point where the destination is selected, rather than deep inside the executor. This cleans up the original kluge implementation of tstoreReceiver.c, and makes it easy to support retrieving results from utility statements inside portals. Thus, you can now do fun things like Bind and Execute a FETCH or EXPLAIN command, and it'll all work as expected (e.g., you can Describe the portal, or use Execute's count parameter to suspend the output partway through). Implementation involves stuffing the utility command's output into a Tuplestore, which would be kind of annoying for huge output sets, but should be quite acceptable for typical uses of utility commands.
* Implement feature of new FE/BE protocol whereby RowDescription identifiesTom Lane2003-05-06
| | | | | | | | | the column by table OID and column number, if it's a simple column reference. Along the way, get rid of reskey/reskeyop fields in Resdoms. Turns out that representation was not convenient for either the planner or the executor; we can make the planner deliver exactly what the executor wants with no more effort. initdb forced due to change in stored rule representation.
* Portal and memory management infrastructure for extended query protocol.Tom Lane2003-05-02
| | | | | | | | | Both plannable queries and utility commands are now always executed within Portals, which have been revamped so that they can handle the load (they used to be good only for single SELECT queries). Restructure code to push command-completion-tag selection logic out of postgres.c, so that it won't have to be duplicated between simple and extended queries. initdb forced due to addition of a field to Query nodes.
* Infrastructure for deducing Param types from context, in the same wayTom Lane2003-04-29
| | | | | | | | | | | that the types of untyped string-literal constants are deduced (ie, when coerce_type is applied to 'em, that's what the type must be). Remove the ancient hack of storing the input Param-types array as a global variable, and put the info into ParseState instead. This touches a lot of files because of adjustment of routine parameter lists, but it's really not a large patch. Note: PREPARE statement still insists on exact specification of parameter types, but that could easily be relaxed now, if we wanted to do so.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-08 13:15:49 +0000