Re: pl/pgsql problem with search_path

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(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:26:24
Message-ID: 2021.1062897984@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2003-09-07 01:37:05 Re: pl/pgsql problem with search_path
Previous Message Eugene Chow 2003-09-06 23:29:45 Re: pl/pgsql problem with search_path