Re: Small bug on CREATE EXTENSION pgq...

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

In response to

Responses

Browse pgsql-hackers by date

  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