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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Regina Obe <lr(at)pcorp(dot)us>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is there a way around function search_path killing SQL function inlining?
Date: 2016-03-10 16:48:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

> 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Grishchenko 2016-03-10 16:56:45 Re: Endless loop calling PL/Python set returning functions
Previous Message David G. Johnston 2016-03-10 16:33:49 Re: Add generate_series(date,date) and generate_series(date,date,integer)