Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path
От | Rene van Paassen |
---|---|
Тема | Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path |
Дата | |
Msg-id | CAOVCA=u-cYhy3BpweJxVWMExGNweJmUOEz5Bo61y064RR2_0zw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 12 March 2012 16:16, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Mon, Mar 5, 2012 at 6:52 AM, <rene.vanpaassen@gmail.com> wrote: > >> I found some unexpected behaviour when changing the schema search path > in > >> combination with plpgsql functions (may be true for other function typ= es > >> too, did not check). This occurs both in 9.1.2 (on Fedora, 64 bit) and > 8.4.9 > >> (Centos 6, 32 bit). I created a small example run with psql, to > demonstrate > >> this. > > > I have a vague feeling this is a known issue. It sure seems like we > > should handle it better, but I'm not sure how hard that would be to > > implement. > > plpgsql intentionally caches the plan for the query as it was built with > the original search_path. There's been talk of adjusting that behavior > but I'm worried that we might break as many cases as we fix ... > But since I can work around the problem by closing and opening the database connection, the "original search_path" is thus the search path that the function happened to run in for the first time with the current database connection. --=20 Ren=E9 van Paassen | ______o____/_| Rene.vanPaassen@gmail.com <[___\_\_-----< t: +31 15 2628685 | o' mobile: +31 6 39846891
В списке pgsql-bugs по дате отправления: