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. -- 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 7: don't forget to increase your free space map settings
