Re: pl/pgsql problem with search_path

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Eugene Chow <gene(at)paragonam(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: pl/pgsql problem with search_path
Date: 2003-09-07 01:40:27
Message-ID: 200309070140.h871eRt02161@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

--
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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-09-07 02:22:03 Re: LOAD broken?
Previous Message Bruce Momjian 2003-09-07 01:37:05 Re: pl/pgsql problem with search_path