Gaetano Mendola wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > This highlights another problem with our plpgsql function caching.
> > >
> > > It's a little disturbing to think that any change in SEARCH_PATH might
> > > force us to discard all cached plans. That could be expensive; and
> > > consider a function that deliberately sets SEARCH_PATH to ensure that
> > > it gets the tables it wants. You wouldn't want such a function to be
> > > unable to cache any plans across calls (not to mention blowing away
> > > every other function's plans, too).
> > >
> > > We'd probably better record with each plan the SEARCH_PATH it was
> > > generated with. Then, as long as that matches the current setting,
> > > we can re-use the plan.
> > >
> > > Of course, none of this is going to happen until someone gets around to
> > > creating infrastructure for flushing cached plans at need. Right at the
> > > moment the answer is going to have to be "don't do that".
> >
> > Yep. I was just surprised it highlighted another failure of cached
> > plans.
>
> There is already a TODO for it ?
Yep:
o Fix problems with complex temporary table creation/destruction
without using PL/PgSQL EXECUTE, needs cache prevention/invalidation
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
