On Mon, Mar 24, 2008 at 9:48 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Add to pl/pgsql TODO:
o Consider invalidating the cache or keeping seperate cached
copies when search_path changes
http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php
IMO,
Merlin Moncure wrote:
On Mon, Mar 24, 2008 at 9:48 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Add to pl/pgsql TODO:
o Consider invalidating the cache or keeping seperate cached
copies when search_path changes
Add to pl/pgsql TODO:
o Consider invalidating the cache or keeping seperate cached
copies when search_path changes
http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php
---
Tom
Greetings,
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
Our case is where we have a number of schemas with identical table
structures but differing table
Stephen Frost [EMAIL PROTECTED] writes:
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
We never considered it so before, either. The plancache code goes out
of its
On Jan 27, 2008 10:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
We never
Merlin Moncure [EMAIL PROTECTED] writes:
On Jan 27, 2008 10:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
If we were to change this, we'd probably have to think in terms of
making the active search_path be part of the lookup key for cached plans.
For the record, IMO it would on balance be better
