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

Поиск
Список
Период
Сортировка
От Regina Obe
Тема RE: "interesting" issue with restore from a pg_dump with a database-wide search_path
Дата
Msg-id 001001d422d8$65c1b160$31451420$@pcorp.us
обсуждение исходный текст
Ответ на Re: "interesting" issue with restore from a pg_dump with a database-wide search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "interesting" issue with restore from a pg_dump with a database-wide search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> 
> > a) In this particular case, I have a function that uses fuzzystrmatch
and is
> used in functional indexes.
> > I unfortunately can't schema qualify the use of soundex, because I
> > don't know where the user may have installed fuzzystrmatch is
> > installed
> > b) Stephen Frost had suggested, perhaps we should have some syntax like
> @extension_loc(fuzzystrmatch)...@ so that one could reference an extension
> dependency location within a function without knowing where it is
installed.
> 
> 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;
> 
> which will cause it to absorb the search path that's set while running the
> extension script, which should be what you want.
> 
>             regards, tom lane

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

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.









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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Missing pg_control crashes postmaster