RE: "interesting" issue with restore from a pg_dump with a database-wide search_path - Mailing list pgsql-hackers

From Regina Obe
Subject RE: "interesting" issue with restore from a pg_dump with a database-wide search_path
Date
Msg-id 001001d422d8$65c1b160$31451420$@pcorp.us
Whole thread Raw
In response to Re: "interesting" issue with restore from a pg_dump with a database-wide search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "interesting" issue with restore from a pg_dump with a database-wide search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
Next
From: Tom Lane
Date:
Subject: Re: Missing pg_control crashes postmaster