Bruce Momjian wrote:
I can confirm this bug in CVS.
Dropping the pkey from table b in fact drops the unique index from it. The SPI plan cached to check if a row deleted from table a is still referenced from table b "can" (and in your case does) use an index scan on table b and is thereby corrupted by dropping the pkey.
Switching to a generally non-cached model for all foreign key checks would be the only workaround at the moment, and I don't see us doing that as it would cause performance to suffer big times for everyone who's system doesn't have a permanent "what's the latest schema" contest going on.
Since all caching procedural languages and all caching custom C functions suffer the same, the correct fix would be to let SPI_saveplan() maintain a hash table of all referenced system cache objects who's entries point to the referencing saved plans and then mark those plans for recompile at system cache invalidation.
I will probably not do it today ... tomorrow doesn't look good either.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
