Re: Foreign Key bug -- 7.4b4

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(at)Yahoo(dot)com #