mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 10:53:25 +02:00
If an inline-able SQL function taking a composite argument is used in a LATERAL subselect, and the composite argument is a lateral reference, the planner could fail with "variable not found in subplan target list", as seen in bug #11703 from Karl Bartel. (The outer function call used in the bug report and in the committed regression test is not really necessary to provoke the bug --- you can get it if you manually expand the outer function into "LATERAL (SELECT inner_function(outer_relation))", too.) The cause of this is that we generate the reltargetlist for the referenced relation before doing eval_const_expressions() on the lateral sub-select's expressions (cf find_lateral_references()), so what's scheduled to be emitted by the referenced relation is a whole-row Var, not the simplified single-column Var produced by optimizing the function's FieldSelect on the whole-row Var. Then setrefs.c fails to match up that lateral reference to what's available from the outer scan. Preserving the FieldSelect optimization in such cases would require either major planner restructuring (to recursively do expression simplification on sub-selects much earlier) or some amazingly ugly kluge to change the reltargetlist of a possibly-already-planned relation. It seems better just to skip the optimization when the Var is from an upper query level; the case is not so common that it's likely anyone will notice a few wasted cycles. AFAICT this problem only occurs for uplevel LATERAL references, so back-patch to 9.3 where LATERAL was added. |
||
---|---|---|
.. | ||
backend | ||
bin | ||
common | ||
include | ||
interfaces | ||
makefiles | ||
pl | ||
port | ||
template | ||
test | ||
timezone | ||
tools | ||
tutorial | ||
.gitignore | ||
bcc32.mak | ||
DEVELOPERS | ||
Makefile | ||
Makefile.global.in | ||
Makefile.shlib | ||
nls-global.mk | ||
win32.mak |