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

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

Previous
From: Tom Lane
Date:
Subject: Re: Missing pg_control crashes postmaster
Next
From: Kohei KaiGai
Date:
Subject: [report] memory leaks in COPY FROM on partitioned table