Robert Haas <robertmh...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
