Re: Foreign Key bug -- 7.4b4

This this a new TODO?

---------------------------------------------------------------------------

Jan Wieck wrote:
> 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 #
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073