aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/spi.c
Commit message (Collapse)AuthorAge
* Add support for invoking parser callback hooks via SPI and in cached plans.Tom Lane2009-11-04
| | | | | | | | | | | | As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
* Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c.Tom Lane2009-10-10
| | | | | | | | | | They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
* Ensure that a cursor has an immutable snapshot throughout its lifespan.Alvaro Herrera2009-10-02
| | | | | | | | | The old coding was using a regular snapshot, referenced elsewhere, that was subject to having its command counter updated. Fix by creating a private copy of the snapshot exclusively for the cursor. Backpatch to 8.4, which is when the bug was introduced during the snapshot management rewrite.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for theHeikki Linnakangas2009-01-21
| | | | | | | case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
* Insert conditional SPI_push/SPI_pop calls into InputFunctionCall,Tom Lane2009-01-07
| | | | | | | | | | | | | | | | | | | | OutputFunctionCall, and friends. This allows SPI-using functions to invoke datatype I/O without concern for the possibility that a SPI-using function will be called (which could be either the I/O function itself, or a function used in a domain check constraint). It's a tad ugly, but not nearly as ugly as what'd be needed to make this work via retail insertion of push/pop operations in all the PLs. This reverts my patch of 2007-01-30 that inserted some retail SPI_push/pop calls into plpgsql; that approach only fixed plpgsql, and not any other PLs. But the other PLs have the issue too, as illustrated by a recent gripe from Christian Schröder. Back-patch to 8.2, which is as far back as this solution will work. It's also as far back as we need to worry about the domain-constraint case, since earlier versions did not attempt to check domain constraints within datatype input. I'm not aware of any old I/O functions that use SPI themselves, so this should be sufficient for a back-patch.
* Fix executor/spi.h to follow our usual conventions for include files, ie,Tom Lane2009-01-07
| | | | | | | | | not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
* Include a pointer to the query's source text in QueryDesc structs. This isTom Lane2009-01-02
| | | | | | | practically free given prior 8.4 changes in plancache and portal management, and it makes it a lot easier for ExecutorStart/Run/End hooks to get at the query text. Extracted from Itagaki Takahiro's pg_stat_statements patch, with minor editorialization.
* Update copyright for 2009.Bruce Momjian2009-01-01
|
* Remove pg_plan_queries()'s now-useless needSnapshot parameter. It's uselessTom Lane2008-12-13
| | | | | in 8.3, too, but I'm not back-patching this change since it would break any extension modules that might be calling that function.
* Clean up the API for DestReceiver objects by eliminating the assumptionTom Lane2008-11-30
| | | | | | | | | | | | that a Portal is a useful and sufficient additional argument for CreateDestReceiver --- it just isn't, in most cases. Instead formalize the approach of passing any needed parameters to the receiver separately. One unexpected benefit of this change is that we can declare typedef Portal in a less surprising location. This patch is just code rearrangement and doesn't change any functionality. I'll tackle the HOLD-cursor-vs-toast problem in a follow-on patch.
* Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple,Tom Lane2008-11-02
| | | | | | | | | | | and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
* Fix SPI_getvalue and SPI_getbinval to range-check the given attribute numberTom Lane2008-10-16
| | | | | | | | | | | | | | according to the TupleDesc's natts, not the number of physical columns in the tuple. The previous coding would do the wrong thing in cases where natts is different from the tuple's column count: either incorrectly report error when it should just treat the column as null, or actually crash due to indexing off the end of the TupleDesc's attribute array. (The second case is probably not possible in modern PG versions, due to more careful handling of inheritance cases than we once had. But it's still a clear lack of robustness here.) The incorrect error indication is ignored by all callers within the core PG distribution, so this bug has no symptoms visible within the core code, but it might well be an issue for add-on packages. So patch all the way back.
* Fix caching of foreign-key-checking queries so that when a replan is needed,Tom Lane2008-09-15
| | | | | | | | we regenerate the SQL query text not merely the plan derived from it. This is needed to handle contingencies such as renaming of a table or column used in an FK. Pre-8.3, such cases worked despite the lack of replanning (because the cached plan needn't actually change), so this is a regression. Per bug #4417 from Benjamin Bihler.
* Adjust things so that the query_string of a cached plan and the sourceText ofTom Lane2008-07-18
| | | | | | | | | | | | | | | | | | | | | | | | a portal are never NULL, but reliably provide the source text of the query. It turns out that there was only one place that was really taking a short-cut, which was the 'EXECUTE' utility statement. That doesn't seem like a sufficiently critical performance hotspot to justify not offering a guarantee of validity of the portal source text. Fix it to copy the source text over from the cached plan. Add Asserts in the places that set up cached plans and portals to reject null source strings, and simplify a bunch of places that formerly needed to guard against nulls. There may be a few places that cons up statements for execution without having any source text at all; I found one such in ConvertTriggerToFK(). It seems sufficient to inject a phony source string in such a case, for instance ProcessUtility((Node *) atstmt, "(generated ALTER TABLE ADD FOREIGN KEY command)", NULL, false, None_Receiver, NULL); We should take a second look at the usage of debug_query_string, particularly the recently added current_query() SQL function. ITAGAKI Takahiro and Tom Lane
* Refactor SPI_cursor_open/SPI_cursor_open_with_args so that the latter setsTom Lane2008-06-01
| | | | | | | | the PARAM_FLAG_CONST flag on the parameters that are passed into the portal, while the former's behavior is unchanged. This should only affect the case where the portal is executing an EXPLAIN; it will cause the generated plan to look more like what would be generated if the portal were actually executing the command being explained. Per gripe from Pavel.
* Improve snapshot manager by keeping explicit track of snapshots.Alvaro Herrera2008-05-12
| | | | | | | | | | | | | There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-12
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* Revert my bad decision of about a year ago to make PortalDefineQueryTom Lane2008-04-02
| | | | | | | | | | | | | | responsible for copying the query string into the new Portal. Such copying is unnecessary in the common code path through exec_simple_query, and in this case it can be enormously expensive because the string might contain a large number of individual commands; we were copying the entire, long string for each command, resulting in O(N^2) behavior for N commands. (This is the cause of bug #4079.) A second problem with it is that PortalDefineQuery really can't risk error, because if it elog's before having set up the Portal, we will leak the plancache refcount that the caller is trying to hand off to the portal. So go back to the design in which the caller is responsible for making sure everything is copied into the portal if necessary.
* Add SPI-level support for executing SQL commands with one-time-use plans,Tom Lane2008-04-01
| | | | | | | | | | | that is commands that have out-of-line parameters but the plan is prepared assuming that the parameter values are constants. This is needed for the plpgsql EXECUTE USING patch, but will probably have use elsewhere. This commit includes the SPI functions and documentation, but no callers nor regression tests. The upcoming EXECUTE USING patch will provide regression-test coverage. I thought committing this separately made sense since it's logically a distinct feature.
* Rename snapmgmt.c/h to snapmgr.c/h, for consistency with other files.Alvaro Herrera2008-03-26
| | | | Per complaint from Tom Lane.
* Separate snapshot management code from tuple visibility code, create aAlvaro Herrera2008-03-26
| | | | | | | | | | | | | snapmgmt.c file for the former. The header files have also been reorganized in three parts: the most basic snapshot definitions are now in a new file snapshot.h, and the also new snapmgmt.h keeps the definitions for snapmgmt.c. tqual.h has been reduced to the bare minimum. This patch is just a first step towards managing live snapshots within a transaction; there is no functionality change. Per my proposal to pgsql-patches on 20080318191940.GB27458@alvh.no-ip.org and subsequent discussion.
* Add a couple of missing FreeQueryDesc calls. Noticed while testing aAlvaro Herrera2008-03-20
| | | | framework to keep track of snapshots in use.
* Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI stack beforeTom Lane2008-02-12
| | | | | | | | | | | | | | | | | | | | | doing anything interesting, such as calling RevalidateCachedPlan(). The necessity of this is demonstrated by an example from Willem Buitendyk: during a replan, the planner might try to evaluate SPI-using functions, and so we'd better be in a clean SPI context. A small downside of this fix is that these two functions will now fail outright if called when not inside a SPI-using procedure (ie, a SPI_connect/SPI_finish pair). The documentation never promised or suggested that that would work, though; and they are normally used in concert with other functions, mainly SPI_prepare, that always have failed in such a case. So the odds of breaking something seem pretty low. In passing, make SPI_is_cursor_plan's error handling convention clearer, and fix documentation's erroneous claim that SPI_cursor_open would return NULL on error. Before 8.3 these functions could not invoke replanning, so there is probably no need for back-patching.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-01
|
* Avoid incrementing the CommandCounter when CommandCounterIncrement is calledTom Lane2007-11-30
| | | | | | | | | | | | | | | | | | | | but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
* Repair bug that allowed RevalidateCachedPlan to attempt to rebuild a cachedTom Lane2007-11-30
| | | | | | | | | | plan before the effects of DDL executed in an immediately prior SPI operation had been absorbed. Per report from Chris Wood. This patch has an unpleasant side effect of causing the number of CommandCounterIncrement()s done by a typical plpgsql function to approximately double. Amelioration of the consequences of that will be undertaken in a separate patch.
* pgindent run for 8.3.Bruce Momjian2007-11-15
|
* Tweak new error messages to match the actual syntax of DECLARE CURSOR.Tom Lane2007-10-25
| | | | | (Last night I copied-and-pasted from the WITH HOLD case, but that's wrong because of the bizarrely irregular syntax specified by the standard.)
* Disallow scrolling of FOR UPDATE/FOR SHARE cursors, so as to avoid problemsTom Lane2007-10-24
| | | | | | | | | | | in corner cases such as re-fetching a just-deleted row. We may be able to relax this someday, but let's find out how many people really care before we invest a lot of work in it. Per report from Heikki and subsequent discussion. While in the neighborhood, make the combination of INSENSITIVE and FOR UPDATE throw an error, since they are semantically incompatible. (Up to now we've accepted but just ignored the INSENSITIVE option of DECLARE CURSOR.)
* HOT updates. When we update a tuple without changing any of its indexedTom Lane2007-09-20
| | | | | | | | | | | | columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
* Repair problems occurring when multiple RI updates have to be done to the sameTom Lane2007-08-15
| | | | | | | | | row within one query: we were firing check triggers before all the updates were done, leading to bogus failures. Fix by making the triggers queued by an RI update go at the end of the outer query's trigger event list, thereby effectively making the processing "breadth-first". This was indeed how it worked pre-8.0, so the bug does not occur in the 7.x branches. Per report from Pavel Stehule.
* Modify processing of DECLARE CURSOR and EXPLAIN so that they can resolve theTom Lane2007-04-27
| | | | | | | | | | | | | | types of unspecified parameters when submitted via extended query protocol. This worked in 8.2 but I had broken it during plancache changes. DECLARE CURSOR is now treated almost exactly like a plain SELECT through parse analysis, rewrite, and planning; only just before sending to the executor do we divert it away to ProcessUtility. This requires a special-case check in a number of places, but practically all of them were already special-casing SELECT INTO, so it's not too ugly. (Maybe it would be a good idea to merge the two by treating IntoClause as a form of utility statement? Not going to worry about that now, though.) That approach doesn't work for EXPLAIN, however, so for that I punted and used a klugy solution of running parse analysis an extra time if under extended query protocol.
* Make plancache store cursor options so it can pass them to planner duringTom Lane2007-04-16
| | | | | | a replan. I had originally thought this was not necessary, but the new SPI facilities create a path whereby queries planned with non-default options can get into the cache, so it is necessary.
* Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql.Tom Lane2007-04-16
| | | | Pavel Stehule, reworked a bit by Tom.
* Expose more cursor-related functionality in SPI: specifically, allowTom Lane2007-04-16
| | | | | | | | | | | access to the planner's cursor-related planning options, and provide new FETCH/MOVE routines that allow access to the full power of those commands. Small refactoring of planner(), pg_plan_query(), and pg_plan_queries() APIs to make it convenient to pass the planning options down from SPI. This is the core-code portion of Pavel Stehule's patch for scrollable cursor support in plpgsql; I'll review and apply the plpgsql changes separately.
* Make _SPI_execute_plan pass the query source string down to ProcessUtilityTom Lane2007-03-25
| | | | | | if possible. I had left this undone in the first pass at the API change for ProcessUtility, but forgot to revisit it after the plancache changes made it possible to do it.
* Remove the prohibition on executing cursor commands through SPI_execute.Tom Lane2007-03-25
| | | | | | | | | Vadim had included this restriction in the original design of the SPI code, but I'm darned if I can see a reason for it. I left the macro definition of SPI_ERROR_CURSOR in place, so as not to needlessly break any SPI callers that are checking for it, but that code will never actually be returned anymore.
* SPI_cursor_open failed to enforce that only read-only queries could beTom Lane2007-03-17
| | | | | | | executed in read_only mode. This could lead to various relatively-subtle failures, such as an allegedly stable function returning non-stable results. Bug goes all the way back to the introduction of read-only mode in 8.0. Per report from Gaetano Mendola.
* Make use of plancache module for SPI plans. In particular, since plpgsqlTom Lane2007-03-15
| | | | | | | | | | | | uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
* First phase of plan-invalidation project: create a plan cache managementTom Lane2007-03-13
| | | | | | | | | | | | | | | | module and teach PREPARE and protocol-level prepared statements to use it. In service of this, rearrange utility-statement processing so that parse analysis does not assume table schemas can't change before execution for utility statements (necessary because we don't attempt to re-acquire locks for utility statements when reusing a stored plan). This requires some refactoring of the ProcessUtility API, but it ends up cleaner anyway, for instance we can get rid of the QueryContext global. Still to do: fix up SPI and related code to use the plan cache; I'm tempted to try to make SQL functions use it too. Also, there are at least some aspects of system state that we want to ensure remain the same during a replan as in the original processing; search_path certainly ought to behave that way for instance, and perhaps there are others.
* Remove the Query structure from the executor's API. This allows us to stopTom Lane2007-02-20
| | | | | | | | | | | | | | | storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
* Enable another five tuple status bits by using the high bits of theBruce Momjian2007-01-09
| | | | | | nattr field, and rename the field. Heikki Linnakangas
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-05
| | | | back-stamped for this.
* 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.
* 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.
* 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.
* pgindent run for 8.2.Bruce Momjian2006-10-04
|
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-31 21:31:32 +0000