• Tom Lane's avatar
    Repair more failures with SubPlans in multi-row VALUES lists. · 41c6f9db
    Tom Lane authored
    Commit 9b63c13f turns out to have been fundamentally misguided:
    the parent node's subPlan list is by no means the only way in which
    a child SubPlan node can be hooked into the outer execution state.
    As shown in bug #16213 from Matt Jibson, we can also get short-lived
    tuple table slots added to the outer es_tupleTable list.  At this point
    I have little faith that there aren't other possible connections as
    well; the long time it took to notice this problem shows that this
    isn't a heavily-exercised situation.
    
    Therefore, revert that fix, returning to the coding that passed a
    NULL parent plan pointer down to the transiently-built subexpressions.
    That gives us a pretty good guarantee that they won't hook into the
    outer executor state in any way.  But then we need some other solution
    to make SubPlans work.  Adopt the solution speculated about in the
    previous commit's log message: do expression initialization at plan
    startup for just those VALUES rows containing SubPlans, abandoning the
    goal of reclaiming memory intra-query for those rows.  In practice it
    seems unlikely that queries containing a vast number of VALUES rows
    would be using SubPlans in them, so this should not give up much.
    
    (BTW, this test case also refutes my claim in connection with the prior
    commit that the issue only arises with use of LATERAL.  That was just
    wrong: some variants of SubLink always produce SubPlans.)
    
    As with previous patch, back-patch to all supported branches.
    
    Discussion: https://postgr.es/m/16213-871ac3bc208ecf23@postgresql.org
    41c6f9db
execnodes.h 85.1 KB