aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
Commit message (Collapse)AuthorAge
* When using a junkfilter, the output tuple should NOT be stored back intoTom Lane2001-05-27
| | | | | | | | 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-27
| | | | Rather surprising we hadn't seen bug reports about this ...
* Make UPDATE and DELETE privileges distinct. Add REFERENCES and TRIGGERPeter Eisentraut2001-05-27
| | | | | privileges. INSERT and COPY FROM now require INSERT (only). Add privileges regression test.
* Enhancement of SPI to get access to portalsJan Wieck2001-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | - 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-15
| | | | | | 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-15
|
* EvalPlanQual was thoroughly broken for concurrent update/delete on inheritanceTom Lane2001-05-15
| | | | | | | | 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-08
| | | | | | | | | 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-07
| | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | 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-23
|
* Remove dashes in comments that don't need them, rewrap with pgindent.Bruce Momjian2001-03-22
|
* pgindent run. Make it all clean.Bruce Momjian2001-03-22
|
* Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatibleTom Lane2001-02-19
| | | | syntax. Fix the RESULT_OID case, which never worked. Add documentation.
* Clean up two rather nasty bugs in operator selection code.Tom Lane2001-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-15
|
* Clean up handling of tuple descriptors so that result-tuple descriptorsTom Lane2001-01-29
| | | | | | | | 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-27
| | | | triggers ... oops ... but the regress tests should have covered this ...
* Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.Bruce Momjian2001-01-24
|
* Clean up per-tuple memory leaks in trigger firing and plpgsqlTom Lane2001-01-22
| | | | expression evaluation.
* Change lcons(x, NIL) to makeList(x) where appropriate.Bruce Momjian2001-01-17
|
* Restructure backend SIGINT/SIGTERM handling so that 'die' interruptsTom Lane2001-01-14
| | | | | | | 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-04
| | | | used before ...
* Update comment.Tom Lane2001-01-01
|
* Fix portability problems recently exposed by regression tests on Alphas.Tom Lane2000-12-27
| | | | | | | | | | 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-13
| | | | output first outer tuple before advancing...
* In SELECT FOR UPDATE, silently ignore null CTIDs, rather than generatingTom Lane2000-12-05
| | | | | | | 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-01
| | | | | 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-16
| | | | | | | 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-12
| | | | | | | | | | | | | | | | | 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.
* ExecEndAppend() neglected to close indices on appended result rels,Tom Lane2000-11-09
| | | | | and improperly prevented the main result rel from being closed if it wasn't one of the Append's own result rels. Per report from Hiroshi.
* Make DROP TABLE rollback-able: postpone physical file delete until commit.Tom Lane2000-11-08
| | | | | | | | | (WAL logging for this is not done yet, however.) Clean up a number of really crufty things that are no longer needed now that DROP behaves nicely. Make temp table mapper do the right things when drop or rename affecting a temp table is rolled back. Also, remove "relation modified while in use" error check, in favor of locking tables at first reference and holding that lock throughout the statement.
* Allow ORDER BY, LIMIT in sub-selects. Fix most (not all) cases whereTom Lane2000-11-05
| | | | | | the grammar did not allow redundant parentheses around sub-selects. Distinguish LIMIT ALL from LIMIT 0; make the latter behave as one would expect.
* Re-implement LIMIT/OFFSET as a plan node type, instead of a hack inTom Lane2000-10-26
| | | | | | 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.
* Remove NO_SECURITY define.Bruce Momjian2000-10-16
|
* Add proofreader's changes to docs.Bruce Momjian2000-10-05
| | | | Fix misspelling of disbursion to dispersion.
* Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet theTom Lane2000-10-05
| | | | | | | | | | | SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
* Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias.Tom Lane2000-09-29
| | | | | | | | | (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
* First cut at full support for OUTER JOINs. There are still a few looseTom Lane2000-09-12
| | | | | ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
* This patch implements a different "relkind"Bruce Momjian2000-09-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for views. Views are now have a "relkind" of RELKIND_VIEW instead of RELKIND_RELATION. Also, views no longer have actual heap storage files. The following changes were made 1. CREATE VIEW sets the new relkind 2. The executor complains if a DELETE or INSERT references a view. 3. DROP RULE complains if an attempt is made to delete a view SELECT rule. 4. CREATE RULE "_RETmytable" AS ON SELECT TO mytable DO INSTEAD ... 1. checks to make sure mytable is empty. 2. sets the relkind to RELKIND_VIEW. 3. deletes the heap storage files. 5. LOCK myview is not allowed. :) 6. the regression test type_sanity was changed to account for the new relkind value. 7. CREATE INDEX ON myview ... is not allowed. 8. VACUUM myview is not allowed. VACUUM automatically skips views when do the entire database. 9. TRUNCATE myview is not allowed. THINGS LEFT TO THINK ABOUT o pg_views o pg_dump o pgsql (\d \dv) o Do we really want to be able to inherit from views? o Is 'DROP TABLE myview' OK? -- Mark Hollomon
* Code cleanup of user name and user id handling in the backend. The currentPeter Eisentraut2000-09-06
| | | | | | | | | | | user is now defined in terms of the user id, the user name is only computed upon request (for display purposes). This is kind of the opposite of the previous state, which would maintain the user name and compute the user id for permission checks. Besides perhaps saving a few cycles (integer vs string), this now creates a single point of attack for changing the user id during a connection, for purposes of "setuid" functions, etc.
* Fix relative path references so that make knowns which dependencies referPeter Eisentraut2000-08-31
| | | | | to one another. Sort out builddir vs srcdir variable namings. Remove some now obsoleted make variables.
* GetAttributeByName and GetAttributeByNum should be declared to returnTom Lane2000-08-24
| | | | Datum, not char*, for portability's sake.
* SQL-language functions are now callable in ordinary fmgr contexts ...Tom Lane2000-08-24
| | | | | | for example, an SQL function can be used in a functional index. (I make no promises about speed, but it'll work ;-).) Clean up and simplify handling of functions returning sets.
* Fix a many-legged critter reported by chifungfan@yahoo.com: under theTom Lane2000-08-22
| | | | | | | | | | right circumstances a hash join executed as a DECLARE CURSOR/FETCH query would crash the backend. Problem as seen in current sources was that the hash tables were stored in a context that was a child of TransactionCommandContext, which got zapped at completion of the FETCH command --- but cursor cleanup executed at COMMIT expected the tables to still be valid. I haven't chased down the details as seen in 7.0.* but I'm sure it's the same general problem.
* Move pg_checkretval out of the planner (where it never belonged) intoTom Lane2000-08-21
| | | | | | pg_proc.c (where it's actually used). Fix it to correctly handle tlists that contain resjunk target items, and improve error messages. This addresses bug reported by Krupnikov 6-July-00.
* Clean up handling of variable-free qual clauses. System now does theTom Lane2000-08-13
| | | | | | | | | | right thing with variable-free clauses that contain noncachable functions, such as 'WHERE random() < 0.5' --- these are evaluated once per potential output tuple. Expressions that contain only Params are now candidates to be indexscan quals --- for example, 'var = ($1 + 1)' can now be indexed. Cope with RelabelType nodes atop potential indexscan variables --- this oversight prevents 7.0.* from recognizing some potentially indexscanable situations.
* Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist'Tom Lane2000-08-08
| | | | | | | | from Param nodes, per discussion a few days ago on pghackers. Add new expression node type FieldSelect that implements the functionality where it's actually needed. Clean up some other unused fields in Func nodes as well. NOTE: initdb forced due to change in stored expression trees for rules.
* Clean up inefficiency in ExecRelCheck, and cause it to do the rightTom Lane2000-08-06
| | | | | | thing when there are multiple result relations. Formerly, during something like 'UPDATE foo*', foo's constraints and *only* foo's constraints would be applied to all foo's children. Wrong-o ...
* Modify heap_open()/heap_openr() API per pghackers discussion of 11 July.Tom Lane2000-08-03
| | | | | | | | | These two routines will now ALWAYS elog() on failure, whether you ask for a lock or not. If you really want to get a NULL return on failure, call the new routines heap_open_nofail()/heap_openr_nofail(). By my count there are only about three places that actually want that behavior. There were rather more than three places that were missing the check they needed to make under the old convention :-(.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-05 21:57:20 +0000