Re: pl/pgsql problem with search_path - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: pl/pgsql problem with search_path
Date
Msg-id 200309070140.h871eRt02161@candle.pha.pa.us
Whole thread Raw
In response to Re: pl/pgsql problem with search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pl/pgsql problem with search_path
Next
From: Tom Lane
Date:
Subject: Re: LOAD broken?