Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path
От | Robert Haas |
---|---|
Тема | Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path |
Дата | |
Msg-id | CA+Tgmoa3bQM72JfFoZSFV5sTohaY9B48tasmq5U4dkYJ0nruLg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6517: Volatile function erroneously optimized, does not consider change in schema path (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6517: Volatile function erroneously optimized, does
not consider change in schema path
|
Список | pgsql-bugs |
On Mon, Mar 12, 2012 at 11:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Mar 5, 2012 at 6:52 AM, =A0<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 types >>> 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 demonst= rate >>> this. > >> I have a vague feeling this is a known issue. =A0It 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. =A0There's been talk of adjusting that behavior > but I'm worried that we might break as many cases as we fix ... IMHO, the problem with the current behavior is that it's neither all one thing nor all the other. Using the definition-time search_path seems defensible, and using the run-time search_path does, too. But we're not consistently doing either one, which doesn't seem good. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: