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
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 |