pgsql: Repair failure with SubPlans in multi-row VALUES lists.
От | Tom Lane |
---|---|
Тема | pgsql: Repair failure with SubPlans in multi-row VALUES lists. |
Дата | |
Msg-id | E1eIfvl-0006Tx-QV@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Repair failure with SubPlans in multi-row VALUES lists. When nodeValuesscan.c was written, it was impossible to have a SubPlan in VALUES --- any sub-SELECT there would have to be uncorrelated and thereby would produce an InitPlan instead. We therefore took a shortcut in the logic that throws away a ValuesScan's per-row expression evaluation data structures. This was broken by the introduction of LATERAL however; a sub-SELECT containing a lateral reference produces a correlated SubPlan. The cleanest fix for this would be to give up the optimization of discarding the expression eval state. But that still seems pretty unappetizing for long VALUES lists. It seems to work to just prevent the subexpressions from hooking into the ValuesScan node's subPlan list, so let's do that and see how well it works. (If this breaks, due to additional connections between the subexpressions and the outer query structures, we might consider compromises like throwing away data only for VALUES rows not containing SubPlans.) Per bug #14924 from Christian Duta. Back-patch to 9.3 where LATERAL was introduced. Discussion: https://postgr.es/m/20171124120836.1463.5310@wrigleys.postgresql.org Branch ------ REL9_5_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ae6ed07841766867ab7c0f04b996deee140dba19 Modified Files -------------- src/backend/executor/nodeValuesscan.c | 21 ++++++++++++++++----- src/test/regress/expected/subselect.out | 30 ++++++++++++++++++++++++++++++ src/test/regress/sql/subselect.sql | 10 ++++++++++ 3 files changed, 56 insertions(+), 5 deletions(-)
В списке pgsql-committers по дате отправления: