On Fri, Aug 12, 2016 at 3:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.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.

Mmm.  Maybe this hypothetical new facility should confine itself to
search_path specifically.

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

Yeah, it's certainly not the sort of thing I'm going to crank out
before breakfast some morning.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to