Re: Small bug on CREATE EXTENSION pgq... - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Small bug on CREATE EXTENSION pgq...
Date
Msg-id 20150129034731.GK3854@tamriel.snowman.net
Whole thread Raw
In response to Re: Small bug on CREATE EXTENSION pgq...  (David Johnston <david.g.johnston@gmail.com>)
Responses Re: Small bug on CREATE EXTENSION pgq...
List pgsql-hackers
* David Johnston (david.g.johnston@gmail.com) wrote:
> On Wednesday, January 28, 2015, Stephen Frost <sfrost@snowman.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

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Possible typo in create_policy.sgml
Next
From: Stephen Frost
Date:
Subject: Re: Possible typo in create_policy.sgml