aboutsummaryrefslogtreecommitdiff
path: root/src/backend/optimizer/plan/setrefs.c
Commit message (Collapse)AuthorAge
* Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.Bruce Momjian2001-01-24
|
* Fix oversight in planning of GROUP queries: when an expression is usedTom Lane2001-01-09
| | | | | | | | as both a GROUP BY item and an output expression, the top-level Group node should just copy up the evaluated expression value from its input, rather than re-evaluating the expression. Aside from any performance benefit this might offer, this avoids a crash when there is a sub-SELECT in said expression.
* 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.
* 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!
* Repair bug reported by ldm@apartia.com: Append nodes, which don'tTom Lane2000-06-04
| | | | | | | | | | | | actually use their targetlist, are given a targetlist that is just a pointer to the first appended plan's targetlist. This is OK, but what is not OK is that any sub-select expressions in said tlist were being entered in the subPlan lists of both the Append and the first appended plan. That led to two startup and two shutdown calls for the same plan node at exec time, which led to crashes. Fix is to not generate a list of subPlans for an Append node. Same problem and fix apply to other node types that don't have a real, functioning targetlist: Material, Sort, Unique, Hash.
* Remove unused include files. Do not touch /port or includes used by defines.Bruce Momjian2000-05-30
|
* Ye-old pgindent run. Same 4-space tabs.Bruce Momjian2000-04-12
|
* Fix extremely nasty little bug observed when a sub-SELECT appears inTom Lane2000-04-04
| | | | | | | | | | | | | | | | | | | | WHERE in a place where it can be part of a nestloop inner indexqual. As the code stood, it put the same physical sub-Plan node into both indxqual and indxqualorig of the IndexScan plan node. That confused later processing in the optimizer (which expected that tracing the subPlan list would visit each subplan node exactly once), and would probably have blown up in the executor if the planner hadn't choked first. Fix by making the 'fixed' indexqual be a complete deep copy of the original indexqual, rather than trying to share nodes below the topmost operator node. This had further ramifications though, because we were making the aforesaid list of sub-Plan nodes during SS_process_sublinks which is run before construction of the 'fixed' indexqual, meaning that the copy of the sub-Plan didn't show up in that list. Fix by rearranging logic so that the sub-Plan list is built by the final set_plan_references pass, not in SS_process_sublinks. This may sound like a mess, but it's actually a good deal cleaner now than it was before, because we are no longer dependent on the assumption that planning will never make a copy of a sub-Plan node.
* Add:Bruce Momjian2000-01-26
| | | | | | * Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
* Tid access method feature from Hiroshi Inoue, Inoue@tpf.co.jpBruce Momjian1999-11-23
|
* Skip invoking set_uppernode_references() for a RESULT nodeTom Lane1999-10-30
| | | | | that has no subplan --- saves a material amount of time for a simple INSERT ... VALUES query.
* Further planner/optimizer cleanups. Move all set_tlist_referencesTom Lane1999-08-22
| | | | | | | | | | and fix_opids processing to a single recursive pass over the plan tree executed at the very tail end of planning, rather than haphazardly here and there at different places. Now that tlist Vars do not get modified until the very end, it's possible to get rid of the klugy var_equal and match_varid partial-matching routines, and just use plain equal() throughout the optimizer. This is a step towards allowing merge and hash joins to be done on expressions instead of only Vars ...
* Major revision of sort-node handling: push knowledge of queryTom Lane1999-08-21
| | | | | | | | | | | | | sort order down into planner, instead of handling it only at the very top level of the planner. This fixes many things. An explicit sort is now avoided if there is a cheaper alternative (typically an indexscan) not only for ORDER BY, but also for the internal sort of GROUP BY. It works even when there is no other reason (such as a WHERE condition) to consider the indexscan. It works for indexes on functions. It works for indexes on functions, backwards. It's just so cool... CAUTION: I have changed the representation of SortClause nodes, therefore THIS UPDATE BREAKS STORED RULES. You will need to initdb.
* Remove extraneous SeqScan node that make_noname was insertingTom Lane1999-08-18
| | | | | | above a Sort or Materialize node. As far as I can tell, the only place that actually needed that was set_tlist_references, which was being lazy about checking to see if it had a noname node to fix or not...
* Clean up routines in setrefs.c by replacing individual treeTom Lane1999-08-09
| | | | walking logic with expression_tree_walker/mutator calls.
* Final cleanup.Bruce Momjian1999-07-16
|
* Remove unused #includes in *.c files.Bruce Momjian1999-07-15
|
* Clean up #include in /include directory. Add scripts for checking includes.Bruce Momjian1999-07-15
|
* Fix problems with grouping/aggregation in queries that useTom Lane1999-06-06
| | | | inheritance ... basically it was completely busted :-(
* Make functions static or NOT_USED as appropriate.Bruce Momjian1999-05-26
|
* Another pgindent run. Sorry folks.Bruce Momjian1999-05-25
|
* pgindent run over code.Bruce Momjian1999-05-25
|
* Replaced targetlist entry in GroupClause by reference numberJan Wieck1999-05-12
| | | | | | | in Resdom and GroupClause so changing of resno's doesn't confuse the grouping any more. Jan
* Fix oversights in flatten_tlistentry and replace_clause_joinvar_refsTom Lane1999-05-06
| | | | that led to CASE expressions not working very well in joined queries.
* Revise union_planner and associated routines to clean up breakageTom Lane1999-05-03
| | | | | from EXCEPT/HAVING patch. Cases involving nontrivial GROUP BY expressions now work again. Also, the code is at least somewhat better documented...
* Several routines in setrefs.c would crash on array refsTom Lane1999-04-29
| | | | due to lack of check for recursing into a null subexpression.
* Insert a test for missing targetlist entry in replace_agg_clause.Tom Lane1999-04-26
|
* Repair some problems in planner's handling of HAVING clauses.Tom Lane1999-04-19
| | | | | This fixes a few of the problems Hiroshi Inoue complained of, but I have not touched the rewrite-related issues.
* Fix a number of places that made faulty assumptions aboutTom Lane1999-02-15
| | | | what is_opclause will accept.
* Change my-function-name-- to my_function_name, and optimizer renames.Bruce Momjian1999-02-13
|
* Rename Temp to Noname for noname tables.Bruce Momjian1999-02-09
|
* Cleanup of source files where 'return' or 'var =' is alone on a line.Bruce Momjian1999-02-03
|
* Optimizer rename ClauseInfo -> RestrictInfo. Update optimizer README.Bruce Momjian1999-02-03
|
* Fix create_rule is->as.Bruce Momjian1999-02-02
|
* pgindent file.Bruce Momjian1999-01-26
|
* Agg/Aggreg cleanup and datetime.sql patch.Bruce Momjian1999-01-25
|
* Rename Aggreg to Aggref.Bruce Momjian1999-01-24
|
* Remove unused Choose node.Bruce Momjian1999-01-23
|
* Hi!Bruce Momjian1999-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INTERSECT and EXCEPT is available for postgresql-v6.4! The patch against v6.4 is included at the end of the current text (in uuencoded form!) I also included the text of my Master's Thesis. (a postscript version). I hope that you find something of it useful and would be happy if parts of it find their way into the PostgreSQL documentation project (If so, tell me, then I send the sources of the document!) The contents of the document are: -) The first chapter might be of less interest as it gives only an overview on SQL. -) The second chapter gives a description on much of PostgreSQL's features (like user defined types etc. and how to use these features) -) The third chapter starts with an overview of PostgreSQL's internal structure with focus on the stages a query has to pass (i.e. parser, planner/optimizer, executor). Then a detailed description of the implementation of the Having clause and the Intersect/Except logic is given. Originally I worked on v6.3.2 but never found time enough to prepare and post a patch. Now I applied the changes to v6.4 to get Intersect and Except working with the new version. Chapter 3 of my documentation deals with the changes against v6.3.2, so keep that in mind when comparing the parts of the code printed there with the patched sources of v6.4. Here are some remarks on the patch. There are some things that have still to be done but at the moment I don't have time to do them myself. (I'm doing my military service at the moment) Sorry for that :-( -) I used a rewrite technique for the implementation of the Except/Intersect logic which rewrites the query to a semantically equivalent query before it is handed to the rewrite system (for views, rules etc.), planner, executor etc. -) In v6.3.2 the types of the attributes of two select statements connected by the UNION keyword had to match 100%. In v6.4 the types only need to be familiar (i.e. int and float can be mixed). Since this feature did not exist when I worked on Intersect/Except it does not work correctly for Except/Intersect queries WHEN USED IN COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the resulting table. This is because until now the types of the attributes of the first select statement have been used for the resulting table. When Intersects and/or Excepts are used in combination with Unions it might happen, that the first select statement of the original query appears at another position in the query which will be executed. The reason for this is the technique used for the implementation of Except/Intersect which does a query rewrite!) NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT queries!!! -) I had to add the field intersect_clause to some data structures but did not find time to implement printfuncs for the new field. This does NOT break the debug modes but when an Except/Intersect is used the query debug output will be the already rewritten query. -) Massive changes to the grammar rules for SELECT and INSERT statements have been necessary (see comments in gram.y and documentation for deatails) in order to be able to use mixed queries like (SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...; -) When using UNION/EXCEPT/INTERSECT you will get: NOTICE: equal: "Don't know if nodes of type xxx are equal". I did not have time to add comparsion support for all the needed nodes, but the default behaviour of the function equal met my requirements. I did not dare to supress this message! That's the reason why the regression test for union will fail: These messages are also included in the union.out file! -) Somebody of you changed the union_planner() function for v6.4 (I copied the targetlist to new_tlist and that was removed and replaced by a cleanup of the original targetlist). These chnages violated some having queries executed against views so I changed it back again. I did not have time to examine the differences between the two versions but now it works :-) If you want to find out, try the file queries/view_having.sql on both versions and compare the results . Two queries won't produce a correct result with your version. regards Stefan
* Add support for the CASE statement in the rewrite handling.Thomas G. Lockhart1998-12-14
| | | | | | Allows (at least some) rules and views. Still some trouble (crashes) with target CASE columns spanning tables, but lots now works.
* Make functions static or ifdef NOT_USED. Prevent pg_version creation.Bruce Momjian1998-10-08
|
* Fix using GroupBy/non-GroupBy expressions in HAVING.Vadim B. Mikheev1998-09-09
|
* OK, folks, here is the pgindent output.Bruce Momjian1998-09-01
|
* Renaming cleanup, no pgindent yet.Bruce Momjian1998-09-01
|
* Cleanup makeTargetEntry and remove internal.c.Bruce Momjian1998-07-20
|
* 1) Queries using the having clause on base tables should work wellBruce Momjian1998-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | now. Here some tested features, (examples included in the patch): 1.1) Subselects in the having clause 1.2) Double nested subselects 1.3) Subselects used in the where clause and in the having clause simultaneously 1.4) Union Selects using having 1.5) Indexes on the base relations are used correctly 1.6) Unallowed Queries are prevented (e.g. qualifications in the having clause that belong to the where clause) 1.7) Insert into as select 2) Queries using the having clause on view relations also work but there are some restrictions: 2.1) Create View as Select ... Having ...; using base tables in the select 2.1.1) The Query rewrite system: 2.1.2) Why are only simple queries allowed against a view from 2.1) ? 2.2) Select ... from testview1, testview2, ... having...; 3) Bug in ExecMergeJoin ?? Regards Stefan
* Remove un-needed braces around single statements.Bruce Momjian1998-06-15
|
* Move HAVING function to proper file.Bruce Momjian1998-04-15
|