On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote: > 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.
Is this a TODO item? -- Bruce Momjian <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
