|
7 | 7 | * Portions Copyright (c) 1994, Regents of the University of California |
8 | 8 | * |
9 | 9 | * IDENTIFICATION |
10 | | - * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.49 2001/03/22 03:59:37 momjian Exp $ |
| 10 | + * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.50 2001/11/30 19:24:15 tgl Exp $ |
11 | 11 | * |
12 | 12 | *------------------------------------------------------------------------- |
13 | 13 | */ |
@@ -324,6 +324,12 @@ make_subplan(SubLink *slink) |
324 | 324 | * is anything more complicated than a plain sequential scan, and |
325 | 325 | * we do it even for seqscan if the qual appears selective enough |
326 | 326 | * to eliminate many tuples. |
| 327 | + * |
| 328 | + * XXX It's pretty ugly to be inserting a MATERIAL node at this |
| 329 | + * point. Since subquery_planner has already run SS_finalize_plan |
| 330 | + * on the subplan tree, we have to kluge up parameter lists for |
| 331 | + * the MATERIAL node. Possibly this could be fixed by postponing |
| 332 | + * SS_finalize_plan processing until setrefs.c is run. |
327 | 333 | */ |
328 | 334 | if (node->parParam==NIL) |
329 | 335 | { |
@@ -362,8 +368,13 @@ make_subplan(SubLink *slink) |
362 | 368 | } |
363 | 369 | if (use_material) |
364 | 370 | { |
365 | | -plan= (Plan*)make_material(plan->targetlist,plan); |
366 | | -node->plan=plan; |
| 371 | +Plan*matplan; |
| 372 | + |
| 373 | +matplan= (Plan*)make_material(plan->targetlist,plan); |
| 374 | +/* kluge --- see comments above */ |
| 375 | +matplan->extParam=listCopy(plan->extParam); |
| 376 | +matplan->locParam=listCopy(plan->locParam); |
| 377 | +node->plan=plan=matplan; |
367 | 378 | } |
368 | 379 | } |
369 | 380 |
|
|