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
> >
> > http://archives.postgresql.or
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
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 Lane
"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
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
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 i
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 contents.
