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@Yahoo.com #