summaryrefslogtreecommitdiff
path: root/src/backend/executor/spi.c
Commit message (Collapse)AuthorAgeFilesLines
* oid is needed, it is added at the end of the struct (after the nullBruce Momjian2002-07-201-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-2/+2
|
* Remove global variable scanCommandId in favor of storing a command IDTom Lane2002-05-211-21/+1
| | | | | | | | | | | 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-151-2/+2
| | | | | | | | | | | | | | | 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-211-3/+4
| | | | | | | | 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-271-26/+34
| | | | | | | | | | | 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-261-3/+3
| | | | | | | 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-141-7/+24
| | | | | | 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-031-6/+28
| | | | 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-211-1/+4
|
* Clean up usage-statistics display code (ShowUsage and friends). StatFpTom Lane2001-11-101-10/+3
| | | | is gone, usage messages now go through elog(DEBUG).
* Fix coredump in plpgsql when trying to return a rowtype result.Tom Lane2001-11-051-1/+35
| | | | Need to return a TupleTableSlot, not just a bare tuple.
* pgindent run on all C files. Java run to follow. initdb/regressionBruce Momjian2001-10-251-45/+44
| | | | tests pass.
* Make SPI's column-accessing functions work for system columns as well asTom Lane2001-10-231-21/+61
| | | | 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-051-5/+3
| | | | | | | | | 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.
* Add a SPI_copytupledesc function that parallels SPI_copytuple --- ie,Tom Lane2001-08-021-3/+30
| | | | | it copies the tupdesc into upper-executor memory. This is necessary for returning tuple descriptors without leaking all of lower exec memory.
* Tweak memory context sizing for saved SPI plans.Tom Lane2001-08-021-20/+27
|
* If spi.c wants to use malloc, it better test for malloc failure.Tom Lane2001-06-011-7/+17
|
* Enhancement of SPI to get access to portalsJan Wieck2001-05-211-9/+312
| | | | | | | | | | | | | | | | | | | | | | | | | - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
* pgindent run. Make it all clean.Bruce Momjian2001-03-221-20/+19
|
* Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatibleTom Lane2001-02-191-5/+13
| | | | syntax. Fix the RESULT_OID case, which never worked. Add documentation.
* Repair guaranteed core dump in SPI_exec(). Guess this routine wasn'tTom Lane2001-01-041-3/+6
| | | | used before ...
* Make tuple receive/print routines TOAST-aware. Formerly, printtup wouldTom Lane2000-12-011-9/+27
| | | | | leak memory when printing a toasted attribute, and printtup_internal didn't work at all...
* Change SearchSysCache coding conventions so that a reference count isTom Lane2000-11-161-4/+7
| | | | | | | maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
* Re-implement LIMIT/OFFSET as a plan node type, instead of a hack inTom Lane2000-10-261-37/+2
| | | | | | ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a cursor declaration will behave in a reasonable fashion, whereas before it was overridden by the FETCH count.
* First phase of memory management rewrite (see backend/utils/mmgr/READMETom Lane2000-06-281-110/+56
| | | | | | | | | | | | | for details). It doesn't really do that much yet, since there are no short-term memory contexts in the executor, but the infrastructure is in place and long-term contexts are handled reasonably. A few long- standing bugs have been fixed, such as 'VACUUM; anything' in a single query string crashing. Also, out-of-memory is now considered a recoverable ERROR, not FATAL. Eliminate a large amount of crufty, now-dead code in and around memory management. Fix problem with holding off SIGTRAP, SIGSEGV, etc in postmaster and backend startup.
* Third round of fmgr updates: eliminate calls using fmgr() andTom Lane2000-05-301-3/+5
| | | | | fmgr_faddr() in favor of new-style calls. Lots of cleanup of sloppy casts to use XXXGetDatum and DatumGetXXX ...
* Fix bug noted by Bruce: FETCH in an already-aborted transaction blockTom Lane2000-04-041-9/+10
| | | | | | | | | | | would crash, due to premature invocation of SetQuerySnapshot(). Clean up problems with handling of multiple queries by splitting pg_parse_and_plan into two routines. The old code would not, for example, do the right thing with END; SELECT... submitted in one query string when it had been in transaction abort state, because it'd decide to skip planning the SELECT before it had executed the END. New arrangement is simpler and doesn't force caller to plan if only parse+rewrite is needed.
* Some changes to prepare for LONG attributes.Jan Wieck1999-12-161-1/+21
| | | | Jan
* Rename several destroy* functions/tags to drop*.Bruce Momjian1999-12-101-2/+2
|
* Add system indexes to match all caches.Bruce Momjian1999-11-221-2/+2
| | | | | | | Make all system indexes unique. Make all cache loads use system indexes. Rename *rel to *relid in inheritance tables. Rename cache names to be clearer.
* New NameStr macro to convert Name to Str. No need for var.data anymore.Bruce Momjian1999-11-071-5/+5
| | | | | | Fewer calls to nameout. Better use of RelationGetRelationName.
* Remove unused #includes in *.c files.Bruce Momjian1999-07-151-4/+1
|
* Another pgindent run. Sorry folks.Bruce Momjian1999-05-251-2/+2
|
* pgindent run over code.Bruce Momjian1999-05-251-31/+33
|
* Rip out QueryTreeList structure, root and branch. QuerytreeTom Lane1999-05-131-47/+31
| | | | | | | | | | lists are now plain old garden-variety Lists, allocated with palloc, rather than specialized expansible-array data allocated with malloc. This substantially simplifies their handling and eliminates several sources of memory leakage. Several basic types of erroneous queries (syntax error, attempt to insert a duplicate key into a unique index) now demonstrably leak zero bytes per query.
* Small cleanups.Bruce Momjian1999-03-301-2/+2
|
* Changes to fix/improve the dynamic loading on NTMarc G. Fournier1999-03-091-4/+4
| | | | From: Horak Daniel <horak@mmp.plzen-city.cz>
* Change my-function-name-- to my_function_name, and optimizer renames.Bruce Momjian1999-02-131-4/+4
|
* Added LIMIT/OFFSET functionality including new regression test for it.Jan Wieck1999-02-081-2/+37
| | | | | | | Removed CURRENT keyword for rule queries and changed rules regression accordingly. CURRENT has beed announced to disappear in v6.5. Jan
* Speedup of PL/pgSQL by calling ExecEvalExpr() directlyJan Wieck1999-01-271-23/+14
| | | | | | instead of SPI_execp() for simple expressions. Jan
* Another SELECT speedup: extract OIDs of column print functionsTom Lane1999-01-271-4/+2
| | | | | only once per SELECT, not once per tuple. 10% here, 10% there, pretty soon you're talking about real speedups ...
* Replace typtoout() and gettypelem() with a single routine,Tom Lane1999-01-241-6/+6
| | | | | | so that fetching an attribute value needs only one SearchSysCacheTuple call instead of two redundant searches. This speeds up a large SELECT by about ten percent, and probably will help GROUP BY and SELECT DISTINCT too.
* Initial attempt to clean up the code...Marc G. Fournier1998-12-141-47/+5
| | | | | | Switch sprintf() to snprintf() Remove any/all #if 0 -or- #ifdef NOT_USED -or- #ifdef FALSE sections of code
* New HeapTuple structure/interface.Vadim B. Mikheev1998-11-271-7/+8
|
* OK, folks, here is the pgindent output.Bruce Momjian1998-09-011-3/+2
|
* Renaming cleanup, no pgindent yet.Bruce Momjian1998-09-011-61/+61
|
* This is the final state of the rule system for 6.4 after theBruce Momjian1998-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
* heap_fetch requires buffer pointer, must be released; heap_getnextBruce Momjian1998-08-191-1/+1
| | | | | | | | | | | | | no longer returns buffer pointer, can be gotten from scan; descriptor; bootstrap can create multi-key indexes; pg_procname index now is multi-key index; oidint2, oidint4, oidname are gone (must be removed from regression tests); use System Cache rather than sequential scan in many places; heap_modifytuple no longer takes buffer parameter; remove unused buffer parameter in a few other functions; oid8 is not index-able; remove some use of single-character variable names; cleanup Buffer variables usage and scan descriptor looping; cleaned up allocation and freeing of tuples; 18k lines of diff;
* pgindent run before 6.3 release, with Thomas' requested changes.Bruce Momjian1998-02-261-51/+52
|
View Lorry Controller Status