Re: "interesting" issue with restore from a pg_dump with a database-wide search_path

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
Дата
Msg-id 6573.1532387049@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: "interesting" issue with restore from a pg_dump with a database-wide search_path  ("Regina Obe" <lr@pcorp.us>)
Список pgsql-hackers
"Regina Obe" <lr@pcorp.us> writes:
>> You don't really need any new syntax for this particular case, I think.
>> You can declare the function in the extension like this:
>> create function ... set search_path from current;

> But then the search_path would be local variable to the function.  Wouldn't
> that impact performance?

Yeah, but it would *work*.  Never put performance before functionality.

> We had originally tried that in PostGIS functions (well not that but
> explicitly setting the functions local search path to where postgis is
> installed by adding a search_path variable to the function)
> And things got 10 times slower.

I can imagine that you'd take a noticeable hit for SQL functions that'd
otherwise be inline-able, but I doubt that it makes much difference for
index functions.

            regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Missing pg_control crashes postmaster
Следующее
От: Kohei KaiGai
Дата:
Сообщение: [report] memory leaks in COPY FROM on partitioned table