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: http://www.postgresql.org/mailpref/pgsql-hackers