Gaetano Mendola wrote:
> 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. #
#================================================== JanWieck@Yahoo.com #