From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small bug on CREATE EXTENSION pgq... |
Date: | 2015-01-29 03:47:31 |
Message-ID: | 20150129034731.GK3854@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* David Johnston (david(dot)g(dot)johnston(at)gmail(dot)com) wrote:
> On Wednesday, January 28, 2015, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Ehh.. Shouldn't we try to take a bit more care that we reset things
> > after a CREATE EXTENSION is run? Not really sure how much effort we
> > want to put into it, but I see a bit of blame on both sides here.
>
> 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."
> Now, if extensions can be handled similarly to how functions operate, where
> one can define function/extension -local settings and have them revert
> after resolution that might be ok.
That, imv, is really what should be happening inside the create
extension script.. I'm not anxious to look into how to make that happen
though.
> That said, while there isn't any way to prevent it the log_min GUCs should
> not be changed by extensions; that decision should be left up to the user.
> The complaint is not that it should be reset but that the installation
> script should not even care what the setting is.
I agree that the script really shouldn't be changing it.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-01-29 04:00:33 | Re: Possible typo in create_policy.sgml |
Previous Message | Stephen Frost | 2015-01-29 03:45:09 | Re: Possible typo in create_policy.sgml |