From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix calculation of plan node extParams to account for the |
Date: | 2006-05-03 00:24:57 |
Message-ID: | 20060503002457.0AF3E9FB1EE@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Fix calculation of plan node extParams to account for the possibility that one
initPlan sets a parameter for another. This could not (I think) happen before
8.1, but it's possible now because the initPlans generated by MIN/MAX
optimization might themselves use initPlans. We attach those initPlans as
siblings of the MIN/MAX ones, not children, to avoid duplicate computation
when multiple MIN/MAX aggregates are present; so this leads to the case of an
initPlan needing the result of a sibling initPlan, which is not possible with
ordinary query nesting. Hadn't been noticed because in most contexts having
too much stuff listed in extParam is fairly harmless. Fixes "plan should not
reference subplan's variable" bug reported by Catalin Pitis.
Modified Files:
--------------
pgsql/src/backend/optimizer/plan:
subselect.c (r1.106 -> r1.107)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c.diff?r1=1.106&r2=1.107)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-03 00:25:07 | pgsql: Fix calculation of plan node extParams to account for the |
Previous Message | Tom Lane | 2006-05-02 22:25:10 | pgsql: Clean up API for ambulkdelete/amvacuumcleanup as per today's |