summaryrefslogtreecommitdiff
path: root/src/backend/executor
Commit message (Collapse)AuthorAgeFilesLines
* pgindent run on all C files. Java run to follow. initdb/regressionBruce Momjian2001-10-2531-411/+301
| | | | 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.
* Keep the contents of ItemPointerData not the pointers so thatHiroshi Inoue2001-09-291-16/+11
| | | | per tuple memory context doesn't discard them.
* Quick-and-dirty fix for recursive plpgsql functions, per bug report fromTom Lane2001-09-211-44/+61
| | | | | | | | Frank Miles 7-Sep-01. This is really just sticking a finger in the dike. Frank's case works now, but we still couldn't support a recursive function returning a set. Really need to restructure querytrees and execution state so that the querytree is *read only*. We've run into this over and over and over again ... it has to happen sometime soon.
* EXPLAIN ANALYZE feature to measure and show actual runtimes and tupleTom Lane2001-09-187-40/+176
| | | | | counts alongside the planner's estimates. By Martijn van Oosterhout, with some further work by Tom Lane.
* Suppress compiler warning.Tom Lane2001-09-171-2/+2
|
* Apply 7.1.3 changes to the current tree also.Hiroshi Inoue2001-09-081-1/+2
|
* Make hashjoin give the right answer with toasted input data.Tom Lane2001-08-131-18/+32
|
* Make OIDs optional, per discussions in pghackers. WITH OIDS is still theTom Lane2001-08-101-2/+2
| | | | | | | | | | | | default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
* Evaluate LIMIT/OFFSET expressions with ExecEvalExprSwitchContext, notTom Lane2001-08-061-9/+11
| | | | ExecEvalExpr, to avoid possible memory leak.
* 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
|
* Partial indexes work again, courtesy of Martijn van Oosterhout.Tom Lane2001-07-161-4/+4
| | | | | | Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
* Restructure index AM interface for index building and index tuple deletion,Tom Lane2001-07-153-30/+28
| | | | | | | | | | | | | | | | | | | | | | | | | per previous discussion on pghackers. Most of the duplicate code in different AMs' ambuild routines has been moved out to a common routine in index.c; this means that all index types now do the right things about inserting recently-dead tuples, etc. (I also removed support for EXTEND INDEX in the ambuild routines, since that's about to go away anyway, and it cluttered the code a lot.) The retail indextuple deletion routines have been replaced by a "bulk delete" routine in which the indexscan is inside the access method. I haven't pushed this change as far as it should go yet, but it should allow considerable simplification of the internal bookkeeping for deletions. Also, add flag columns to pg_am to eliminate various hardcoded tests on AM OIDs, and remove unused pg_am columns. Fix rtree and gist index types to not attempt to store NULLs; before this, gist usually crashed, while rtree managed not to crash but computed wacko bounding boxes for NULL entries (which might have had something to do with the performance problems we've heard about occasionally). Add AtEOXact routines to hash, rtree, and gist, all of which have static state that needs to be reset after an error. We discovered this need long ago for btree, but missed the other guys. Oh, one more thing: concurrent VACUUM is now the default.
* Statistical system views (yet without the config stuff, butJan Wieck2001-06-223-6/+6
| | | | | | | it's hard to keep such massive changes in sync with the tree so I need to get it in and work from there now). Jan
* Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing booleanTom Lane2001-06-191-1/+137
| | | | | | | tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
* Make planner compute the number of hash buckets the same way thatTom Lane2001-06-111-94/+119
| | | | nodeHash.c will compute it (by sharing code).
* If spi.c wants to use malloc, it better test for malloc failure.Tom Lane2001-06-011-7/+17
|
* Clean up some minor problems exposed by further thought about Panon's bugTom Lane2001-06-011-16/+19
| | | | | | | | | | | | | | report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
* When using a junkfilter, the output tuple should NOT be stored back intoTom Lane2001-05-272-12/+35
| | | | | | | | the same tuple slot that the raw tuple came from, because that slot has the wrong tuple descriptor. Store it into its own slot with the correct descriptor, instead. This repairs problems with SPI functions seeing inappropriate tuple descriptors --- for example, plpgsql code failing to cope with SELECT FOR UPDATE.
* Cause ExecCountSlots() accounting to bear some relationship to reality.Tom Lane2001-05-277-15/+15
| | | | Rather surprising we hadn't seen bug reports about this ...
* Make UPDATE and DELETE privileges distinct. Add REFERENCES and TRIGGERPeter Eisentraut2001-05-271-8/+7
| | | | | privileges. INSERT and COPY FROM now require INSERT (only). Add privileges regression test.
* 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
* Remove unnecessary EvalPlanQual support code --- since this plan nodeTom Lane2001-05-151-31/+10
| | | | | | type never scans a relation directly, it can't be an EPQ target. Explicitly drop subplan's tuple table to ensure we have no buffer pin leaks.
* Some badly needed documentation about EvalPlanQual.Tom Lane2001-05-151-0/+99
|
* EvalPlanQual was thoroughly broken for concurrent update/delete on inheritanceTom Lane2001-05-152-160/+238
| | | | | | | | trees (mostly my fault). Repair. Also fix long-standing bug in ExecReplace: after recomputing a concurrently updated tuple, we must recheck constraints. Make EvalPlanQual leak memory with somewhat less enthusiasm than before, although plugging leaks fully will require more changes than I care to risk in a dot-release.
* Append and SubqueryScan nodes were not passing changed-parameter signals downTom Lane2001-05-082-8/+30
| | | | | | | | | to their children, leading to misbehavior if they had any children that paid attention to chgParam (most plan node types don't). Append's bug has been there a long time, but nobody had noticed because it used to be difficult to create a query where an Append would be used below the top level of a plan; so there were never any parameters getting passed down. SubqueryScan is new in 7.1 ... and I'd modeled its behavior on Append :-(
* Rewrite of planner statistics-gathering code. ANALYZE is now available asTom Lane2001-05-071-44/+35
| | | | | | | | | | | | | | | | | a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
* Kluge solution for Alex Pilosov's report of problems with whole-tupleTom Lane2001-04-191-9/+20
| | | | | | | | | function arguments in join queries: copy the tuples into TransactionCommandContext so they don't get recycled too soon. This is horrid, but not any worse than 7.0 or before, which also leaked such tuples until end of query. A proper fix will require allowing tuple datums to be physically stored inside larger tuple datums, which opens up a bunch of issues that can't realistically be solved for 7.1.1.
* Fix comments that were mis-wrapped, for Tom Lane.Bruce Momjian2001-03-233-10/+12
|
* Remove dashes in comments that don't need them, rewrap with pgindent.Bruce Momjian2001-03-2225-1698/+1309
|
* pgindent run. Make it all clean.Bruce Momjian2001-03-2224-383/+475
|
* 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.
* Clean up two rather nasty bugs in operator selection code.Tom Lane2001-02-162-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. If there is exactly one pg_operator entry of the right name and oprkind, oper() and related routines would return that entry whether its input type had anything to do with the request or not. This is just premature optimization: we shouldn't return the single candidate until after we verify that it really is a valid candidate, ie, is at least coercion-compatible with the given types. 2. oper() and related routines only promise a coercion-compatible result. Unfortunately, there were quite a few callers that assumed the returned operator is binary-compatible with the given datatype; they would proceed to call it without making any datatype coercions. These callers include sorting, grouping, aggregation, and VACUUM ANALYZE. In general I think it is appropriate for these callers to require an exact or binary-compatible match, so I've added a new routine compatible_oper() that only succeeds if it can find an operator that doesn't require any run-time conversions. Callers now call oper() or compatible_oper() depending on whether they are prepared to deal with type conversion or not. The upshot of these bugs is revealed by the following silliness in PL/Tcl's selftest: it creates an operator @< on int4, and then tries to use it to sort a char(N) column. The system would let it do that :-( (and evidently has done so since 6.3 :-( :-(). The result in this case was just a silly sort order, but the reverse combination would've provoked coredump from trying to dereference integers. With this fix you get more reasonable behavior: pltcl_test=# select * from T_pkey1 order by key1, key2 using @<; ERROR: Unable to identify an operator '@<' for types 'bpchar' and 'bpchar' You will have to retype this query using an explicit cast
* Update comments about memory management.Tom Lane2001-02-151-1/+13
|
* Clean up handling of tuple descriptors so that result-tuple descriptorsTom Lane2001-01-2914-704/+358
| | | | | | | | allocated by plan nodes are not leaked at end of query. This doesn't really matter for normal queries, but it sure does for queries invoked repetitively inside SQL functions. Clean up some other grotty code associated with tupdescs, and fix a few other memory leaks exposed by tests with simple SQL functions.
* Looks like I broke cases involving combinations of deferred update/deleteTom Lane2001-01-271-7/+4
| | | | triggers ... oops ... but the regress tests should have covered this ...
* Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.Bruce Momjian2001-01-2429-58/+58
|
* Clean up per-tuple memory leaks in trigger firing and plpgsqlTom Lane2001-01-223-54/+57
| | | | expression evaluation.
* Change lcons(x, NIL) to makeList(x) where appropriate.Bruce Momjian2001-01-171-2/+2
|
* Restructure backend SIGINT/SIGTERM handling so that 'die' interruptsTom Lane2001-01-141-5/+3
| | | | | | | are treated more like 'cancel' interrupts: the signal handler sets a flag that is examined at well-defined spots, rather than trying to cope with an interrupt that might happen anywhere. See pghackers discussion of 1/12/01.
* Repair guaranteed core dump in SPI_exec(). Guess this routine wasn'tTom Lane2001-01-041-3/+6
| | | | used before ...
* Update comment.Tom Lane2001-01-011-2/+5
|
* Fix portability problems recently exposed by regression tests on Alphas.Tom Lane2000-12-272-38/+22
| | | | | | | | | | 1. Distinguish cases where a Datum representing a tuple datatype is an OID from cases where it is a pointer to TupleTableSlot, and make sure we use the right typlen in each case. 2. Make fetchatt() and related code support 8-byte by-value datatypes on machines where Datum is 8 bytes. Centralize knowledge of the available by-value datatype sizes in two macros in tupmacs.h, so that this will be easier if we ever have to do it again.
* Fix thinko for case of outer join where inner table is empty: shouldTom Lane2000-12-131-5/+6
| | | | output first outer tuple before advancing...
* In SELECT FOR UPDATE, silently ignore null CTIDs, rather than generatingTom Lane2000-12-051-7/+9
| | | | | | | an error as we used to. In an OUTER JOIN scenario, retrieving a null CTID from one of the input relations is entirely expected. We still want to lock the input rows from the other relations, so just ignore the null and keep going.
* 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-167-59/+66
| | | | | | | 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.
* Restructure handling of inheritance queries so that they work with outerTom Lane2000-11-127-382/+258
| | | | | | | | | | | | | | | | | joins, and clean things up a good deal at the same time. Append plan node no longer hacks on rangetable at runtime --- instead, all child tables are given their own RT entries during planning. Concept of multiple target tables pushed up into execMain, replacing bug-prone implementation within nodeAppend. Planner now supports generating Append plans for inheritance sets either at the top of the plan (the old way) or at the bottom. Expanding at the bottom is appropriate for tables used as sources, since they may appear inside an outer join; but we must still expand at the top when the target of an UPDATE or DELETE is an inheritance set, because we actually need a different targetlist and junkfilter for each target table in that case. Fortunately a target table can't be inside an outer join... Bizarre mutual recursion between union_planner and prepunion.c is gone --- in fact, union_planner doesn't really have much to do with union queries anymore, so I renamed it grouping_planner.
View Lorry Controller Status