aboutsummaryrefslogtreecommitdiff
path: root/src/backend/nodes/outfuncs.c
Commit message (Collapse)AuthorAge
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-31
| | | | | | | | Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
* Instead of supposing (wrongly, in the general case) that the rowtypeTom Lane2004-12-11
| | | | | | | | of an inheritance child table is binary-compatible with the rowtype of its parent, invent an expression node type that does the conversion correctly. Fixes the new bug exhibited by Kris Shannon as well as a lot of old bugs that would only show up when using multiple inheritance or after altering the parent table.
* Pgindent run for 8.0.Bruce Momjian2004-08-29
|
* Update copyright to 2004.Bruce Momjian2004-08-29
|
* Support USING INDEX TABLESPACE clause for PRIMARY KEY and UNIQUETom Lane2004-08-02
| | | | constraints. Christopher Kings-Lynne.
* Tablespaces. Alternate database locations are dead, long live tablespaces.Tom Lane2004-06-18
| | | | | | | | | There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
* Support assignment to subfields of composite columns in UPDATE and INSERT.Tom Lane2004-06-09
| | | | | | | | As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
* Use the new List API function names throughout the backend, and disable theNeil Conway2004-05-30
| | | | | list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
* Reimplement the linked list data structure used throughout the backend.Neil Conway2004-05-26
| | | | | | | | | | | | | | | | In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
* Promote row expressions to full-fledged citizens of the expression syntax,Tom Lane2004-05-10
| | | | | | | | | | rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
* Alter string format used for integer and OID lists in stored rules.Tom Lane2004-05-08
| | | | | | | | This simplifies and speeds up the reader by letting it get the representation right the first time, rather than correcting it after-the-fact. Also, after int and OID lists become separate node types per Neil's pending patch, this will let us treat these lists as just plain Nodes instead of requiring separate read/write macros the way we have now.
* Rewrite nodeRead() in a less obfuscated fashion, per discussion withTom Lane2004-05-06
| | | | Neil Conway.
* Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... ENDTom Lane2004-03-17
| | | | | | | | so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
* Micro-opt: replace calls likeNeil Conway2004-01-31
| | | | | | | appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
* Correct error introduced in recent hasoids changes --- it's not a boolTom Lane2004-01-22
| | | | field anymore.
* Fix permission-checking bug reported by Tim Burgess 10-Feb-03 (this timeTom Lane2004-01-14
| | | | | | | | | for sure...). Rather than relying on the query context of a rangetable entry to identify what permissions it wants checked, store a full AclMode mask in each RTE, and check exactly those bits. This allows an RTE specifying, say, INSERT privilege on a view to be copied into a derived UPDATE query without changing meaning. Per recent discussion thread. initdb forced due to change of stored rule representation.
* Instead of rechecking lossy index operators by putting them into theTom Lane2004-01-06
| | | | | | | | | regular qpqual ('filter condition'), add special-purpose code to nodeIndexscan.c to recheck them. This ends being almost no net addition of code, because the removal of planner code balances out the extra executor code, but it is significantly more efficient when a lossy operator is involved in an OR indexscan. The old implementation had to recheck the entire indexqual in such cases.
* Adjust indexscan planning logic to keep RestrictInfo nodes associatedTom Lane2004-01-05
| | | | | | | | | | | with index qual clauses in the Path representation. This saves a little work during createplan and (probably more importantly) allows reuse of cached selectivity estimates during indexscan planning. Also fix latent bug: wrong plan would have been generated for a 'special operator' used in a nestloop-inner-indexscan join qual, because the special operator would not have gotten into the list of quals to recheck. This bug is only latent because at present the special-operator code could never trigger on a join qual, but sooner or later someone will want to do it.
* Improve UniquePath logic to detect the case where the input is alreadyTom Lane2004-01-05
| | | | | known unique (eg, it is a SELECT DISTINCT ... subquery), and not do a redundant unique-ification step.
* Add the ability to extract OR indexscan conditions from OR-of-ANDTom Lane2004-01-05
| | | | | | | join conditions in which each OR subclause includes a constraint on the same relation. This implements the other useful side-effect of conversion to CNF format, without its unpleasant side-effects. As per pghackers discussion of a few weeks ago.
* Merge restrictlist_selectivity into clauselist_selectivity byTom Lane2004-01-04
| | | | | | | | teaching the latter to accept either RestrictInfo nodes or bare clause expressions; and cache the selectivity result in the RestrictInfo node when possible. This extends the caching behavior of approx_selectivity to many more contexts, and should reduce duplicate selectivity calculations.
* Rewrite OR indexscan processing to be more flexible. We can now for theTom Lane2004-01-04
| | | | | | | | | first time generate an OR indexscan for a two-column index when the WHERE condition is like 'col1 = foo AND (col2 = bar OR col2 = baz)' --- before, the OR had to be on the first column of the index or we'd not notice the possibility of using it. Some progress towards extracting OR indexscans from subclauses of an OR that references multiple relations, too, although this code is #ifdef'd out because it needs more work.
* Adjust the definition of RestrictInfo's left_relids and right_relidsTom Lane2003-12-30
| | | | | | | | | | fields: now they are valid whenever the clause is a binary opclause, not only when it is a potential join clause (there is a new boolean field canjoin to signal the latter condition). This lets us avoid recomputing the relid sets over and over while examining indexes. Still more work to do to make this as useful as it could be, because there are places that could use the info but don't have access to the RestrictInfo node.
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-29
|
* Get rid of hashkeys field of Hash plan node, since it's redundant withTom Lane2003-11-25
| | | | | | the hashclauses field of the parent HashJoin. This avoids problems with duplicated links to SubPlans in hash clauses, as per report from Andrew Holm-Hansen.
* Cross-data-type comparisons are now indexable by btrees, pursuant to myTom Lane2003-11-12
| | | | | | | | | | pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
* Add operator strategy and comparison-value datatype fields to ScanKey.Tom Lane2003-11-09
| | | | | | | | | | | Remove the 'strategy map' code, which was a large amount of mechanism that no longer had any use except reverse-mapping from procedure OID to strategy number. Passing the strategy number to the index AM in the first place is simpler and faster. This is a preliminary step in planned support for cross-datatype index operations. I'm committing it now since the ScanKeyEntryInitialize() API change touches quite a lot of files, and I want to commit those changes before the tree drifts under me.
* Fix ARRAY[] construct so that in multidimensional case, elements canTom Lane2003-08-17
| | | | | | | | be anything yielding an array of the proper kind, not only sub-ARRAY[] constructs; do subscript checking at runtime not parse time. Also, adjust array_cat to make array || array comply with the SQL99 spec. Joe Conway
* Another pgindent run with updated typedefs.Bruce Momjian2003-08-08
|
* Update copyrights to 2003.Bruce Momjian2003-08-04
|
* pgindent run.Bruce Momjian2003-08-04
|
* A visit from the message-style police ...Tom Lane2003-07-28
|
* Error message editing in backend/bootstrap, /lib, /nodes, /port.Tom Lane2003-07-22
|
* Code review for UPDATE tab SET col = DEFAULT patch ... whack it aroundTom Lane2003-07-03
| | | | so it has some chance of working in rules ...
* Support expressions of the form 'scalar op ANY (array)' andTom Lane2003-06-29
| | | | | | | | | | 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
* Back out array mega-patch.Bruce Momjian2003-06-25
| | | | Joe Conway
* Array mega-patch.Bruce Momjian2003-06-24
| | | | Joe Conway
* Adjust nestloop-with-inner-indexscan plan generation so that we catchTom Lane2003-06-15
| | | | | | | some cases of redundant clauses that were formerly not caught. We have to special-case this because the clauses involved never get attached to the same join restrictlist and so the existing logic does not notice that they are redundant.
* Implement outer-level aggregates to conform to the SQL spec, withTom Lane2003-06-06
| | | | | | | | extensions to support our historical behavior. An aggregate belongs to the closest query level of any of the variables in its argument, or the current query level if there are no variables (e.g., COUNT(*)). The implementation involves adding an agglevelsup field to Aggref, and treating outer aggregates like outer variables at planning time.
* Replace functional-index facility with expressional indexes. Any columnTom Lane2003-05-28
| | | | | | | | | | | of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
* 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 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?
* First phase of work on array improvements. ARRAY[x,y,z] constructorTom Lane2003-04-08
| | | | | | | expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
* 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.
* COALESCE() and NULLIF() are now first-class expressions, not macrosTom Lane2003-02-16
| | | | | that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
* Get rid of last few vestiges of parsetree dependency on grammar tokenTom Lane2003-02-10
| | | | | | codes, per discussion from last March. parse.h should now be included *only* by gram.y, scan.l, keywords.c, parser.c. This prevents surprising misbehavior after seemingly-trivial grammar adjustments.
* Create a distinction between Lists of integers and Lists of OIDs, to getTom Lane2003-02-09
| | | | | | rid of the assumption that sizeof(Oid)==sizeof(int). This is one small step towards someday supporting 8-byte OIDs. For the moment, it doesn't do much except get rid of a lot of unsightly casts.
* Make further use of new bitmapset code: executor's chgParam, extParam,Tom Lane2003-02-09
| | | | | | | | locParam lists can be converted to bitmapsets to speed updating. Also, replace 'locParam' with 'allParam', which contains all the paramIDs relevant to the node (i.e., the union of extParam and locParam); this saves a step during SetChangedParamList() without costing anything elsewhere.
* Replace planner's representation of relation sets, per pghackers discussion.Tom Lane2003-02-08
| | | | | Instead of Lists of integers, we now store variable-length bitmap sets. This should be faster as well as less error-prone.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 23:39:12 +0000