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

On Thu, Mar 10, 2016 at 11:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
> 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).

Let's introduce a new variant of SET that only affects the lexical
scope of the function to which it is attached, and then do what you
said. That would be full of win, because actually I think in nearly
every case that's the behavior people actually want. There's a reason
why (for example) Perl started out with dynamic scoping (local) and
then eventually introduced lexical scoping (my): it's because lexical
scoping makes writing correct programs easier to a greater degree than
dynamic scoping. That's basically the same problem we're hitting here
- and not only here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company