aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execQual.c
Commit message (Collapse)AuthorAge
* Make eval_const_expressions() preserve typmod when simplifying something likeTom Lane2007-09-06
| | | | | | | | | | | null::char(3) to a simple Const node. (It already worked for non-null values, but not when we skipped evaluation of a strict coercion function.) This prevents loss of typmod knowledge in situations such as exhibited in bug #3598. Unfortunately there seems no good way to fix that bug in 8.1 and 8.2, because they simply don't carry a typmod for a plain Const node. In passing I made all the other callers of makeNullConst supply "real" typmod values too, though I think it probably doesn't matter anywhere else.
* Extend whole-row Var evaluation to cope with the case that the sub-planTom Lane2007-08-31
| | | | | | | | generating the tuples has resjunk output columns. This is not possible for simple table scans but can happen when evaluating a whole-row Var for a view. Per example from Patryk Kordylewski. The problem exists back to 8.0 but I'm not going to risk back-patching further than 8.2 because of the many changes in this area.
* Improve UPDATE/DELETE WHERE CURRENT OF so that they can be used from plpgsqlTom Lane2007-06-11
| | | | | | | with a plpgsql-defined cursor. The underlying mechanism for this is that the main SQL engine will now take "WHERE CURRENT OF $n" where $n is a refcursor parameter. Not sure if we should document that fact or consider it an implementation detail. Per discussion with Pavel Stehule.
* Support UPDATE/DELETE WHERE CURRENT OF cursor_name, per SQL standard.Tom Lane2007-06-11
| | | | | | | | | Along the way, allow FOR UPDATE in non-WITH-HOLD cursors; there may once have been a reason to disallow that, but it seems to work now, and it's really rather necessary if you want to select a row via a cursor and then update it in a concurrent-safe fashion. Original patch by Arul Shaji, rather heavily editorialized by Tom Lane.
* Downgrade implicit casts to text to be assignment-only, except for the onesTom Lane2007-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
* Support varlena fields with single-byte headers and unaligned storage.Tom Lane2007-04-06
| | | | | | | | | This commit breaks any code that assumes that the mere act of forming a tuple (without writing it to disk) does not "toast" any fields. While all available regression tests pass, I'm not totally sure that we've fixed every nook and cranny, especially in contrib. Greg Stark with some help from Tom Lane
* Fix array coercion expressions to ensure that the correct volatility isTom Lane2007-03-27
| | | | | | | | | seen by code inspecting the expression. The best way to do this seems to be to drop the original representation as a function invocation, and instead make a special expression node type that represents applying the element-type coercion function to each array element. In this way the element function is exposed and will be checked for volatility. Per report from Guillaume Smet.
* Replace direct assignments to VARATT_SIZEP(x) with SET_VARSIZE(x, len).Tom Lane2007-02-27
| | | | | | | | | | | Get rid of VARATT_SIZE and VARATT_DATA, which were simply redundant with VARSIZE and VARDATA, and as a consequence almost no code was using the longer names. Rename the length fields of struct varlena and various derived structures to catch anyplace that was accessing them directly; and clean up various places so caught. In itself this patch doesn't change any behavior at all, but it is necessary infrastructure if we hope to play any games with the representation of varlena headers. Greg Stark and Tom Lane
* Get rid of the separate EState for subplans, and just let them share theTom Lane2007-02-27
| | | | | | | | | parent query's EState. Now that there's a single flat rangetable for both the main plan and subplans, there's no need anymore for a separate EState, and removing it allows cleaning up some crufty code in nodeSubplan.c and nodeSubqueryscan.c. Should be a tad faster too, although any difference will probably be hard to measure. This is the last bit of subsidiary mop-up work from changing to a flat rangetable.
* Remove typmod checking from the recent security-related patches. It turnsTom Lane2007-02-06
| | | | | | | | | | | | | out that ExecEvalVar and friends don't necessarily have access to a tuple descriptor with correct typmod: it definitely can contain -1, and possibly might contain other values that are different from the Var's value. Arguably this should be cleaned up someday, but it's not a simple change, and in any case typmod discrepancies don't pose a security hazard. Per reports from numerous people :-( I'm not entirely sure whether the failure can occur in 8.0 --- the simple test cases reported so far don't trigger it there. But back-patch the change all the way anyway.
* Implement XMLSERIALIZE for real. Analogously, make the xml to text castPeter Eisentraut2007-02-03
| | | | | | | | | observe the xmloption. Reorganize the representation of the XML option in the parse tree and the API to make it easier to manage and understand. Add regression tests for parsing back XML expressions.
* Repair failure to check that a table is still compatible with a previouslyTom Lane2007-02-02
| | | | | | | | | | | | | | | | | | | | | | made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached query plans: they could contain Vars that claim a column has a different type than it now has. Fix this by checking during plan startup that Vars at relation scan level match the current relation tuple descriptor. Since at that point we already have at least AccessShareLock, we can be sure the column type will not change underneath us later in the query. However, since a backend's locks do not conflict against itself, there is still a hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE while a query is in progress in the current backend. Seal that hole by rejecting ALTER TABLE whenever the target relation is already open in the current backend. This is a significant security hole: not only can one trivially crash the backend, but with appropriate misuse of pass-by-reference datatypes it is possible to read out arbitrary locations in the server process's memory, which could allow retrieving database content the user should not be able to see. Our thanks to Jeff Trout for the initial report. Security: CVE-2007-0556
* Wording cleanup for error messages. Also change can't -> cannot.Bruce Momjian2007-02-01
| | | | | | | | | | | | | | Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
* Various fixes in the logic of XML functions:Peter Eisentraut2007-01-25
| | | | | | | | | | | | | | | | - Add new SQL command SET XML OPTION (also available via regular GUC) to control the DOCUMENT vs. CONTENT option in implicit parsing and serialization operations. - Subtle corrections in the handling of the standalone property in xmlroot(). - Allow xmlroot() to work on content fragments. - Subtle corrections in the handling of the version property in xmlconcat(). - Code refactoring for producing XML declarations.
* Fix xmlconcat by properly merging the XML declarations. Add aggregatePeter Eisentraut2007-01-20
| | | | function xmlagg.
* Add support for xmlval IS DOCUMENT expression.Peter Eisentraut2007-01-14
|
* Use XML output escaping also in XMLFOREST.Peter Eisentraut2007-01-12
|
* Use libxml's xmlwriter API for producing XML elements, instead of doingPeter Eisentraut2007-01-10
| | | | | our own printing dance. This does a better job of quoting and escaping the values.
* Some fine-tuning of xmlpi in corner cases:Peter Eisentraut2007-01-07
| | | | | | - correct error codes - do syntax checks in correct order - strip leading spaces of argument
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-05
| | | | back-stamped for this.
* Code review for XML patch. Instill a bit of sanity in the location ofTom Lane2006-12-24
| | | | | | | the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
* Restructure operator classes to allow improved handling of cross-data-typeTom Lane2006-12-23
| | | | | | | | | | | | | | | | cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
* Initial SQL/XML support: xml data type and initial set of functions.Peter Eisentraut2006-12-21
|
* Small message equalization fixPeter Eisentraut2006-11-17
|
* Remove a 15-year old comment questioning behavior that is now well-Neil Conway2006-11-08
| | | | | established: referencing an undefined parameter should result in an error, not NULL.
* Repair bug #2694 concerning an ARRAY[] construct whose inputs are emptyTom Lane2006-11-06
| | | | | | | | | | sub-arrays. Per discussion, if all inputs are empty arrays then result must be an empty array too, whereas a mix of empty and nonempty arrays should (and already did) draw an error. In the back branches, the construct was strict: any NULL input immediately yielded a NULL output; so I left that behavior alone. HEAD was simply ignoring NULL sub-arrays, which doesn't seem very sensible. For lack of a better idea it now treats NULL sub-arrays the same as empty ones.
* Message style improvementsPeter Eisentraut2006-10-06
|
* pgindent run for 8.2.Bruce Momjian2006-10-04
|
* Fix IS NULL and IS NOT NULL tests on row-valued expressions to conform toTom Lane2006-09-28
| | | | | | | | | | | | the SQL spec, viz IS NULL is true if all the row's fields are null, IS NOT NULL is true if all the row's fields are not null. The former coding got this right for a limited number of cases with IS NULL (ie, those where it could disassemble a ROW constructor at parse time), but was entirely wrong for IS NOT NULL. Per report from Teodor. I desisted from changing the behavior for arrays, since on closer inspection it's not clear that there's any support for that in the SQL spec. This probably needs more consideration.
* Aggregate functions now support multiple input arguments. I also tookTom Lane2006-07-27
| | | | | | | | the opportunity to treat COUNT(*) as a zero-argument aggregate instead of the old hack that equated it to COUNT(1); this is materially cleaner (no more weird ANYOID cases) and ought to be at least a tiny bit faster. Original patch by Sergey Koposov; review, documentation, simple regression tests, pg_dump and psql support by moi.
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-14
|
* Fix problems with cached tuple descriptors disappearing while still in useTom Lane2006-06-16
| | | | | | | | | | by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
* Simplify ParamListInfo data structure to support only numbered parameters,Tom Lane2006-04-22
| | | | | | | not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
* Add a CHECK_FOR_INTERRUPTS() to the loop in ExecMakeTableFunctionResult.Tom Lane2006-03-10
| | | | Otherwise you can't cancel queries like select ... from generate_series(1,1000000).
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-05
|
* Implement SQL-compliant treatment of row comparisons for < <= > >= casesTom Lane2005-12-28
| | | | | | | | | | | | | | | | (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
* Fix problem with whole-row Vars referencing sub-select outputs, perTom Lane2005-12-14
| | | | | example from Jim Dew. Add some simple regression tests, since this is an area we seem to break regularly :-(
* Re-run pgindent, fixing a problem where comment lines after a blankBruce Momjian2005-11-22
| | | | | | | | | comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
* Make SQL arrays support null elements. This commit fixes the core arrayTom Lane2005-11-17
| | | | | | | | functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
* Better solution to the problem of labeling whole-row Datums that areTom Lane2005-10-19
| | | | | | generated from subquery outputs: use the type info stored in the Var itself. To avoid making ExecEvalVar and slot_getattr more complex and slower, I split out the whole-row case into a separate ExecEval routine.
* Ensure that the Datum generated from a whole-row Var contains validTom Lane2005-10-19
| | | | | | type ID information even when it's a record type. This is needed to handle whole-row Vars referencing subquery outputs. Per example from Richard Huxton.
* Standard pgindent run for 8.1.Bruce Momjian2005-10-15
|
* Add Oracle-compatible GREATEST and LEAST functions. Pavel StehuleTom Lane2005-06-26
|
* Remove some unnecessary code: since ExecMakeFunctionResultNoSets does notTom Lane2005-05-12
| | | | | want to handle set inputs, it should just pass NULL for isDone, not make its own failure check.
* Add some defenses against functions declared to return set that don'tTom Lane2005-05-09
| | | | actually follow the protocol; per example from Kris Jurka.
* For some reason access/tupmacs.h has been #including utils/memutils.h,Tom Lane2005-05-06
| | | | | | | which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
* Merge Resdom nodes into TargetEntry nodes to simplify code and save aTom Lane2005-04-06
| | | | | | | | | few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
* Convert oidvector and int2vector into variable-length arrays. ThisTom Lane2005-03-29
| | | | | | | | | | | | | change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
* Use InitFunctionCallInfoData() macro instead of MemSet in performanceTom Lane2005-03-22
| | | | critical places in execQual. By Atsushi Ogawa; some minor cleanup by moi.
* Revise TupleTableSlot code to avoid unnecessary construction and disassemblyTom Lane2005-03-16
| | | | | | | | | | | | | | | | | | | | | of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.