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 wrote:
> Stephen Frost <sfrost@snowman.net> 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 way to maintain the same path that was used initially, and
> I think that's what it should do: a cache module should avoid letting
> the semantics of what it's cached change without the caller's knowledge.
> 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.
>
> > Would it be possible to have this case handled?
>
> It's far too late to reconsider this point for 8.3. If you want to
> bring it up for 8.4, we could think about what the behavioral and
> performance implications would really be. In the meantime, the answer
> is the same as it's always been: if that's what you want, use EXECUTE.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +