From: | "Gaetano Mendola" <mendola(at)bigfoot(dot)com> |
---|---|
To: | <pgsql-bugs(at)postgresql(dot)org> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Subject: | Re: pl/pgsql problem with search_path |
Date: | 2003-09-07 17:19:08 |
Message-ID: | 005c01c37564$2989ec30$f3710b3e@mm.eutelsat.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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 ?
Regards
Gaetano Mendola
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-07 21:59:36 | Re: pl/pgsql problem with search_path |
Previous Message | Tom Lane | 2003-09-07 02:22:03 | Re: LOAD broken? |