summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-01-28 17:43:57 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2012-01-28 17:43:57 -0500
commit7c1719bc68ec1c347e7c80c3735bf3373e765f35 (patch)
tree347f18c3e52ef0cc406195b0c9f8720c347d30d1 /src/backend/access/gist/gistproc.c
parent672614cf2137b2a3778c69de8d73770d84790e44 (diff)
downloadpostgresql-7c1719bc68ec1c347e7c80c3735bf3373e765f35.tar.gz
Fix handling of data-modifying CTE subplans in EvalPlanQual.
We can't just skip initializing such subplans, because the referencing CTE node will expect to find the subplan available when it initializes. That in turn means that ExecInitModifyTable must allow the case (which actually it needed to do anyway, since there's no guarantee that ModifyTable is exactly at the top of the CTE plan tree). So move the complaint about not being allowed in EvalPlanQual mode to execution instead of initialization. Testing turned up yet another problem, which is that we'd try to re-initialize the result relation's index list, leading to leaks and dangling pointers. Per report from Phil Sorber. Back-patch to 9.1 where data-modifying CTEs were introduced.
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions