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(at)Yahoo(dot)com #
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

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