aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/spi.c
Commit message (Collapse)AuthorAge
* 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.
* Code review for holdable-cursors patch. Fix error recovery, memoryTom Lane2003-04-29
| | | | | context sloppiness, some other things. Includes Neil's mopup patch of 22-Apr.
* Put back encoding-conversion step in processing of incoming queries;Tom Lane2003-04-27
| | | | | | | | | | I had inadvertently omitted it while rearranging things to support length-counted incoming messages. Also, change the parser's API back to accepting a 'char *' query string instead of 'StringInfo', as the latter wasn't buying us anything except overhead. (I think when I put it in I had some notion of making the parser API 8-bit-clean, but seeing that flex depends on null-terminated input, that's not really ever gonna happen.)
* Infrastructure for upgraded error reporting mechanism. elog.c isTom Lane2003-04-24
| | | | | | | rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
* This patch implements holdable cursors, following the proposalBruce Momjian2003-03-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (materialization into a tuple store) discussed on pgsql-hackers earlier. I've updated the documentation and the regression tests. Notes on the implementation: - I needed to change the tuple store API slightly -- it assumes that it won't be used to hold data across transaction boundaries, so the temp files that it uses for on-disk storage are automatically reclaimed at end-of-transaction. I added a flag to tuplestore_begin_heap() to control this behavior. Is changing the tuple store API in this fashion OK? - in order to store executor results in a tuple store, I added a new CommandDest. This works well for the most part, with one exception: the current DestFunction API doesn't provide enough information to allow the Executor to store results into an arbitrary tuple store (where the particular tuple store to use is chosen by the call site of ExecutorRun). To workaround this, I've temporarily hacked up a solution that works, but is not ideal: since the receiveTuple DestFunction is passed the portal name, we can use that to lookup the Portal data structure for the cursor and then use that to get at the tuple store the Portal is using. This unnecessarily ties the Portal code with the tupleReceiver code, but it works... The proper fix for this is probably to change the DestFunction API -- Tom suggested passing the full QueryDesc to the receiveTuple function. In that case, callers of ExecutorRun could "subclass" QueryDesc to add any additional fields that their particular CommandDest needed to get access to. This approach would work, but I'd like to think about it for a little bit longer before deciding which route to go. In the mean time, the code works fine, so I don't think a fix is urgent. - (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and adjusted the behavior of SCROLL in accordance with the discussion on -hackers. - (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml Neil Conway
* Implement SQL92-compatible FIRST, LAST, ABSOLUTE n, RELATIVE n optionsTom Lane2003-03-11
| | | | for FETCH and MOVE.
* Restructure parsetree representation of DECLARE CURSOR: now it's aTom Lane2003-03-10
| | | | | | | | | | | | utility statement (DeclareCursorStmt) with a SELECT query dangling from it, rather than a SELECT query with a few unusual fields in it. Add code to determine whether a planned query can safely be run backwards. If DECLARE CURSOR specifies SCROLL, ensure that the plan can be run backwards by adding a Materialize plan node if it can't. Without SCROLL, you get an error if you try to fetch backwards from a cursor that can't handle it. (There is still some discussion about what the exact behavior should be, but this is necessary infrastructure in any case.) Along the way, make EXPLAIN DECLARE CURSOR work.
* Fix SPI result logic for case where there are multiple statements of theTom Lane2003-02-14
| | | | same type in a rule. Per bug report from Pavel Hanak.
* SPI_exec shouldn't return SPI_OK_SELECT if it hasn't actually returnedTom Lane2003-01-29
| | | | | a tuple table. Fixes core dump in pltcl (and probably other PLs) when executing a query rewritten by a rule. Per bug report from Wolfgang Walter.
* Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTOTom Lane2003-01-21
| | | | | | | | that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
* Adjust Tcl-related code to compile cleanly with Tcl 8.4 (add const modifiers asTom Lane2002-12-30
| | | | needed). Some desultory const-ification of SPI interface to support this.
* Skip unnecessary plan-copying now that plan trees are read-only in theTom Lane2002-12-17
| | | | executor.
* Tweak default memory context allocation policy so that a context is notTom Lane2002-12-15
| | | | | | | | | given any malloc block until something is first allocated in it; but thereafter, MemoryContextReset won't release that first malloc block. This preserves the quick-reset property of the original policy, without forcing 8K to be allocated to every context whether any of it is ever used or not. Also, remove some more no-longer-needed explicit freeing during ExecEndPlan.
* Revise executor APIs so that all per-query state structure is built inTom Lane2002-12-15
| | | | | | a per-query memory context created by CreateExecutorState --- and destroyed by FreeExecutorState. This provides a final solution to the longstanding problem of memory leaked by various ExecEndNode calls.
* Phase 1 of read-only-plans project: cause executor state nodes to pointTom Lane2002-12-05
| | | | | | | | | | to plan nodes, not vice-versa. All executor state nodes now inherit from struct PlanState. Copying of plan trees has been simplified by not storing a list of SubPlans in Plan nodes (eliminating duplicate links). The executor still needs such a list, but it can build it during ExecutorStart since it has to scan the plan tree anyway. No initdb forced since no stored-on-disk structures changed, but you will need a full recompile because of node-numbering changes.
* Add new palloc0 call as merge of palloc and MemSet(0).Bruce Momjian2002-11-13
|
* Back out use of palloc0 in place if palloc/MemSet. Seems constant lenBruce Momjian2002-11-11
| | | | to MemSet is a performance boost.
* Merge palloc()/MemSet(0) calls into a single palloc0() call.Bruce Momjian2002-11-10
|
* Make SPI's execution of querystrings follow the rules agreed to forTom Lane2002-10-14
| | | | | | | command status at the interactive level. SPI_processed, etc are set in the same way as the returned command status would have been set if the same querystring were issued interactively. Per gripe from Michael Paesold 25-Sep-02.
* pgindent run.Bruce Momjian2002-09-04
|
* Code review for HeapTupleHeader changes. Add version number to page headersTom Lane2002-09-02
| | | | | | | | | | (overlaying low byte of page size) and add HEAP_HASOID bit to t_infomask, per earlier discussion. Simplify scheme for overlaying fields in tuple header (no need for cmax to live in more than one place). Don't try to clear infomask status bits in tqual.c --- not safe to do it there. Don't try to force output table of a SELECT INTO to have OIDs, either. Get rid of unnecessarily complex three-state scheme for TupleDesc.tdhasoids, which has already caused one recent failure. Improve documentation.
* oid is needed, it is added at the end of the struct (after the nullBruce Momjian2002-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap, if present). Per Tom Lane's suggestion the information whether a tuple has an oid or not is carried in the tuple descriptor. For debugging reasons tdhasoid is of type char, not bool. There are predefined values for WITHOID, WITHOUTOID and UNDEFOID. This patch has been generated against a cvs snapshot from last week and I don't expect it to apply cleanly to current sources. While I post it here for public review, I'm working on a new version against a current snapshot. (There's been heavy activity recently; hope to catch up some day ...) This is a long patch; if it is too hard to swallow, I can provide it in smaller pieces: Part 1: Accessor macros Part 2: tdhasoid in TupDesc Part 3: Regression test Part 4: Parameter withoid to heap_addheader Part 5: Eliminate t_oid from HeapTupleHeader Part 2 is the most hairy part because of changes in the executor and even in the parser; the other parts are straightforward. Up to part 4 the patched postmaster stays binary compatible to databases created with an unpatched version. Part 5 is small (100 lines) and finally breaks compatibility. Manfred Koizar
* Update copyright to 2002.Bruce Momjian2002-06-20
|
* Remove global variable scanCommandId in favor of storing a command IDTom Lane2002-05-21
| | | | | | | | | | | in snapshots, per my proposal of a few days ago. Also, tweak heapam.c routines (heap_insert, heap_update, heap_delete, heap_mark4update) to be passed the command ID to use, instead of doing GetCurrentCommandID. For catalog updates they'll still get passed current command ID, but for updates generated from the main executor they'll get passed the command ID saved in the snapshot the query is using. This should fix some corner cases associated with functions and triggers that advance current command ID while an outer query is still in progress.
* The contents of command.c, creatinh.c, define.c, remove.c and rename.cTom Lane2002-04-15
| | | | | | | | | | | | | | | have been divided according to the type of object manipulated - so ALTER TABLE code is in tablecmds.c, aggregate commands in aggregatecmds.c and so on. A few common support routines remain in define.c (prototypes in src/include/commands/defrem.h). No code has been changed except for includes to reflect the new files. The prototypes for aggregatecmds.c, functioncmds.c, operatorcmds.c, and typecmds.c remain in src/include/commands/defrem.h. From John Gray <jgray@azuli.co.uk>
* First phase of SCHEMA changes, concentrating on fixing the grammar andTom Lane2002-03-21
| | | | | | | | the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
* Clean up BeginCommand and related routines. BeginCommand and EndCommandTom Lane2002-02-27
| | | | | | | | | | | are now both invoked once per received SQL command (raw parsetree) from pg_exec_query_string. BeginCommand is actually just an empty routine at the moment --- all its former operations have been pushed into tuple receiver setup routines in printtup.c. This makes for a clean distinction between BeginCommand/EndCommand (once per command) and the tuple receiver setup/teardown routines (once per ExecutorRun call), whereas the old code was quite ad hoc. Along the way, clean up the calling conventions for ExecutorRun a little bit.
* Restructure command-completion-report code so that there is just oneTom Lane2002-02-26
| | | | | | | report for each received SQL command, regardless of rewriting activity. Also ensure that this report comes from the 'original' command, not the last command generated by rewrite; this fixes 7.2 breakage for INSERT commands that have actions added by rules. Fernando Nasser and Tom Lane.
* Ensure that a cursor is scanned under the same scanCommandId it wasTom Lane2002-02-14
| | | | | | originally created with, so that the set of visible tuples does not change as a result of other activity. This essentially makes PG cursors INSENSITIVE per the SQL92 definition. See bug report of 13-Feb-02.
* SPI_cursor_open must copy by-reference parameter values into theTom Lane2002-01-03
| | | | portal's memory context, so that they will live as long as the portal does.
* Insert CommandCounterIncrement call into SPI_cursor_open.Tom Lane2001-11-21
|
* Clean up usage-statistics display code (ShowUsage and friends). StatFpTom Lane2001-11-10
| | | | is gone, usage messages now go through elog(DEBUG).
* Fix coredump in plpgsql when trying to return a rowtype result.Tom Lane2001-11-05
| | | | Need to return a TupleTableSlot, not just a bare tuple.
* pgindent run on all C files. Java run to follow. initdb/regressionBruce Momjian2001-10-25
| | | | tests pass.
* Make SPI's column-accessing functions work for system columns as well asTom Lane2001-10-23
| | | | user columns. Needed for foreign keys on OID, but useful in general.
* Further cleanup of dynahash.c API, in pursuit of portability andTom Lane2001-10-05
| | | | | | | | | readability. Bizarre '(long *) TRUE' return convention is gone, in favor of just raising an error internally in dynahash.c when we detect hashtable corruption. HashTableWalk is gone, in favor of using hash_seq_search directly, since it had no hope of working with non-LONGALIGNable datatypes. Simplify some other code that was made undesirably grotty by promixity to HashTableWalk.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-31 09:49:03 +0000