aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/cache/relcache.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-08-08 17:01:11 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-08-08 17:01:11 +0000
commit30fd8ec799d50e14ca33c6255e2bd6387b23c0d2 (patch)
treea6a40833845b16596e7ca9fe50477b35b3b76195 /src/backend/utils/cache/relcache.c
parentaf95d7aa63be1d03bad6070d090874d3dfa046e8 (diff)
downloadpostgresql-30fd8ec799d50e14ca33c6255e2bd6387b23c0d2.tar.gz
postgresql-30fd8ec799d50e14ca33c6255e2bd6387b23c0d2.zip
Install checks in executor startup to ensure that the tuples produced by an
INSERT or UPDATE will match the target table's current rowtype. In pre-8.3 releases inconsistency can arise with stale cached plans, as reported by Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb 2007; I'm not sure why we thought there was no risk on the insertion side.) In 8.3 and HEAD this problem should be impossible due to plan cache invalidation management, but it seems prudent to make the check anyway. Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there seems no way to abuse a stale plan comparably.
Diffstat (limited to 'src/backend/utils/cache/relcache.c')
0 files changed, 0 insertions, 0 deletions