Re: pl/pgsql Plan Invalidation and search_path

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pl/pgsql Plan Invalidation and search_path
Дата
Msg-id 17108.1201491913@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pl/pgsql Plan Invalidation and search_path  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pl/pgsql Plan Invalidation and search_path  ("Merlin Moncure" <mmoncure@gmail.com>)
Re: pl/pgsql Plan Invalidation and search_path  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: pl/pgsql Plan Invalidation and search_path
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable