aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/tsquery_gist.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2007-10-24 18:37:09 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2007-10-24 18:37:09 +0000
commitc29a9c37bf6bdaaaa65ccbcd4c69c596691134e1 (patch)
treec7df7fd2c22d5007ff6901800714d93bc4ce8a4c /src/backend/utils/adt/tsquery_gist.c
parent9226ba817b19999d51d39a0a2bde810160d0cf24 (diff)
downloadpostgresql-c29a9c37bf6bdaaaa65ccbcd4c69c596691134e1.tar.gz
postgresql-c29a9c37bf6bdaaaa65ccbcd4c69c596691134e1.zip
Fix UPDATE/DELETE WHERE CURRENT OF to support repeated update and update-
then-delete on the current cursor row. The basic fix is that nodeTidscan.c has to apply heap_get_latest_tid() to the current-scan-TID obtained from the cursor query; this ensures we get the latest row version to work with. However, since that only works if the query plan is a TID scan, we also have to hack the planner to make sure only that type of plan will be selected. (Formerly, the planner might decide to apply a seqscan if the table is very small. This change is probably a Good Thing anyway, since it's hard to see how a seqscan could really win.) That means the execQual.c code to support CurrentOfExpr as a regular expression type is dead code, so replace it with just an elog(). Also, add regression tests covering these cases. Note that the added tests expose the fact that re-fetching an updated row misbehaves if the cursor used FOR UPDATE. That's an independent bug that should be fixed later. Per report from Dharmendra Goyal.
Diffstat (limited to 'src/backend/utils/adt/tsquery_gist.c')
0 files changed, 0 insertions, 0 deletions