Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Aug 12, 2016 at 3:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> Mmm. Maybe this hypothetical new facility should confine itself to
> search_path specifically.
Well, that would be sad, because examples like enable_seqscan seem about
as useful as search_path.
Assuming that the implementation involved something like calling guc.c to
tell it to push and later pop a new semantic level (within which outer
single-level GUC settings don't apply), it's possible that the problem
mentioned above could be solved by having the planner push a semantic
level during inline_function and simplify_function. In normal execution
you could perhaps do it in fmgr.c's handlers. Not sure whether we'd
need to have spi.c know about it in order to make PL functions work
nicely.
regards, tom lane
