From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jerry Sievers <gsievers19(at)comcast(dot)net> |
Subject: | Re: Small bug on CREATE EXTENSION pgq... |
Date: | 2015-01-29 04:25:51 |
Message-ID: | 16695.1422505551@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * David Johnston (david(dot)g(dot)johnston(at)gmail(dot)com) wrote:
>> Fair enough but "reset" to what? I don't know the internal mechanics but
>> if the session default is "warning" and a local change sets it to "notice"
>> then an unconditional reset would not get us back to the intended value.
> Yeah, we'd really want to reset it to "what it was before."
An extension script runs as a single transaction, so SET LOCAL could've
been used to accomplish the result without trashing the session-lifespan
setting.
I'm not sure whether or not there was good reason to be changing the
setting at all, but it's entirely on the extension script's head that
it didn't do this in a less invasive way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-01-29 05:01:28 | Re: pg_upgrade and rsync |
Previous Message | Stephen Frost | 2015-01-29 04:22:20 | Re: Possible typo in create_policy.sgml |