On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Hmm. The meaning of funcs.inline depends on the search_path, not just
> > during dump restoration but all the time. So anything uses it under a
> > different search_path setting than the normal one will have this kind
> > of problem; not just dump/restore.
>
> Yeah, I see no reason to claim that this is a dump/restore-specific
> problem.
>
> > I don't have a very good idea what to do about that.
>
> The safe way to write SQL-language functions to be search-path-proof
> is to schema-qualify the names in them, or to add a "SET search_path"
> clause to the function definition.
>
> The problem with the latter approach is that it defeats inlining.
> I thought for a minute that maybe we could teach the planner to do
> inlining anyway by parsing the function body with the adjusted
> search_path, but that doesn't really preserve the same semantics
> (a SET would change the environment for called functions too).
>
> So for now, the recommendation has to be "write functions you want
> to inline with schema qualifications". If you're worried about
> preserving relocatability of an extension containing such functions,
> the @extschema@ feature might help.
Is this a TODO item?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
