Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Date
Msg-id CAM-w4HM=ydO4vuT-ZkAPT5uXNKs4w089djXxmoEbHc+GSz2KtA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
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.

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.

-- 
greg



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] Microvacuum support for Hash Index
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Failure in commit_ts tap tests