Re: PoC plpgsql - possibility to force custom or generic plan
Jim Nasby <jim.nasby@bluetreble.com>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Greg Stark <stark@mit.edu>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-01T21:45:24Z
Lists: pgsql-hackers
On 1/27/17 4:14 AM, Greg Stark wrote: > On 25 January 2017 at 20:06, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> GUCs support SET LOCAL, but that's not the same as local scoping because the >> setting stays in effect unless the substrans aborts. What I'd like is the >> ability to set a GUC in a plpgsql block *and have the setting revert on >> block exit*. > > I'm wondering which GUCs you have in mind to use this with. It's been quite some time since I messed with this; the only case I remember right now is wanting to do a temporary SET ROLE in an "exec" function: SELECT tools.exec( 'some sql;', role := 'superuser_role' ); To do that, exec has to remember what the current role is and then set it back (as well as remembering to do SET LOCAL in case an error happens. > Because what you're describing is dynamic scoping and I'm wondering if > what you're really looking for is lexical scoping. That would be more > in line with how PL/PgSQL variables are scoped and with how #pragmas > usually work. But it would probably not be easy to reconcile with how > GUCs work. Right, because GUCs aren't even simply dynamically scoped; they're dynamically scoped with transaction support. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
Commits
-
Add plan_cache_mode setting
- f7cb2842bf47 12.0 landed
-
Add some noreturn attributes to help static analyzers
- a044378ce2f6 11.0 cited
-
document when PREPARE uses generic plans
- fab9d1da4a21 9.6.0 cited
-
Redesign the plancache mechanism for more flexibility and efficiency.
- e6faf910d750 9.2.0 cited