Bruce Momjian <[EMAIL PROTECTED]> writes:
> This this a new TODO?
No, it's already there, in multiple guises even.
o Fix problems with complex temporary table creation/destruction
without using PL/PgSQL EXECUTE, needs cache prevention/invalidation
* Flush cached query plans whe
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
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
Bruce Momjian wrote:
I can confirm this bug in CVS.
Something is cached, if you quit your psql session after
droping the constraint, and you start another psql session
the problem disappear.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: y
I can confirm this bug in CVS.
---
Rod Taylor wrote:
-- Start of PGP signed section.
> May have posted this earlier...
>
> It would seem that caching the plans for foreign keys has some unwanted
> side effects.
>
>
> tes
May have posted this earlier...
It would seem that caching the plans for foreign keys has some unwanted
side effects.
test=# select version();
version
PostgreSQL 7.4beta4 on i386-portbld-fr
