| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PoC plpgsql - possibility to force custom or generic plan |
| Date: | 2017-01-27 12:14:22 |
| Message-ID: | CAM-w4HM=ydO4vuT-ZkAPT5uXNKs4w089djXxmoEbHc+GSz2KtA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 25 January 2017 at 20:06, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-01-27 12:22:06 | Re: Failure in commit_ts tap tests |
| Previous Message | Ashutosh Sharma | 2017-01-27 11:45:04 | Re: Microvacuum support for Hash Index |