Re: pl/pgsql Plan Invalidation and search_path

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. +