Re: Is there a way around function search_path killing SQL function inlining?

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 +