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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Regina Obe" <lr(at)pcorp(dot)us>
Cc: "'Joshua D(dot) Drake'" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "'Paul Ramsey'" <pramsey(at)cleverelephant(dot)ca>
Subject: Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
Date: 2018-07-23 23:04:09
Message-ID: 6573.1532387049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Regina Obe" <lr(at)pcorp(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2018-07-24 00:41:52 [report] memory leaks in COPY FROM on partitioned table
Previous Message Tom Lane 2018-07-23 23:00:30 Re: Missing pg_control crashes postmaster