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-08-12 19:22:27
Message-ID: 10648.1471029747@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Hm. I think that sounds a lot easier than it actually is. As an example,
this would mean that we'd want such a search_path setting to apply during
parse analysis of a function's body, but not during planning, because it
should not apply during inlining or const-folding of another function.
On the other hand, if someone tried to "SET enable_seqscan = off" with
this new scope (a highly reasonable thing to do), that certainly should
apply during planning.

It might be practical to make it work, but it will be ticklish to
get the scope of the settings to be non-surprising.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-08-12 19:25:05 Re: Is there a way around function search_path killing SQL function inlining?
Previous Message Robert Haas 2016-08-12 19:22:24 Re: Parallel tuplesort, partitioning, merging, and the future