Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

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)