Re: pl/pgsql problem with search_path
От | Gaetano Mendola |
---|---|
Тема | Re: pl/pgsql problem with search_path |
Дата | |
Msg-id | 005c01c37564$2989ec30$f3710b3e@mm.eutelsat.org обсуждение исходный текст |
Ответ на | Re: pl/pgsql problem with search_path (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pl/pgsql problem with search_path
|
Список | pgsql-bugs |
"Bruce Momjian" <pgman@candle.pha.pa.us> wrote: > 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. There is already a TODO for it ? Regards Gaetano Mendola
В списке pgsql-bugs по дате отправления: