| commit | 891fde37a7c559998a79fcc6b7d6d8a10c852fff | |
| author | tgl <tgl> | |
| Fri, 8 Aug 2008 17:01:11 +0000 (8 17:01 +0000) | ||
| committer | tgl <tgl> | |
| Fri, 8 Aug 2008 17:01:11 +0000 (8 17:01 +0000) | ||
| tree | bd2010004d7a86981c78fbdbb9fdd760653f80b3 | treesnapshot (tar.gz zip) |
| parent | 9c19cb06e89a52f1e75a5a56f6a0100b23250898 | commitdiff |
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.
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.
| src/backend/executor/execMain.c | diffblobblamehistory |