* Bruce Momjian (bruce@momjian.us) wrote:
> 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?
For my 2c, yes, but what we actually need is a way to reference
functions in *other* extensions, which might wish to be relocatable.
Even if they don't wish to be relocatable, we don't have any way to say
"replace this string with the schema name of this extension". In other
words, we need something like:
@extschema{'postgis'}@
Which could then be used by extensions that depend on the PostGIS
extension to fully-qualify their function calls.
Thanks!
Stephen
