Back-patch fix to copy sub-Query nodes before planning them. This

fixes problems with subselects appearing in contexts like COALESCE or
BETWEEN, where parser will make multiple links to same subexpression.
This commit is contained in:
Tom Lane 2000-09-23 21:00:05 +00:00
parent c3aab02939
commit 3017000115

View file

@ -7,7 +7,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.36 2000/04/14 00:19:16 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.36.2.1 2000/09/23 21:00:05 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -136,13 +136,24 @@ make_subplan(SubLink *slink)
PlannerQueryLevel++; /* we become child */
/* Check to see if this node was already processed; if so we have
* trouble. Someday should change tree representation so that we can
* cope with multiple links to the same subquery, but for now...
/*
* Check to see if this node was already processed; if so we have
* trouble. We check to see if the linked-to Query appears to have
* been planned already, too.
*/
if (subquery == NULL)
elog(ERROR, "make_subplan: invalid expression structure (SubLink already processed?)");
if (subquery->base_rel_list != NIL)
elog(ERROR, "make_subplan: invalid expression structure (subquery already processed?)");
/*
* Copy the source Query node. This is a quick and dirty kluge to resolve
* the fact that the parser can generate trees with multiple links to the
* same sub-Query node, but the planner wants to scribble on the Query.
* Try to clean this up when we do querytree redesign...
*/
subquery = (Query *) copyObject(subquery);
/*
* For an EXISTS subplan, tell lower-level planner to expect that only
* the first tuple will be retrieved. For ALL and ANY subplans, we