Re: Small bug on CREATE EXTENSION pgq...

On Wednesday, January 28, 2015, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * David G Johnston (david(dot)g(dot)johnston(at)gmail(dot)com <javascript:;>) wrote:
> > Jerry Sievers-3 wrote
> > > Hackers; I noticed this trying to import a large pg_dump file with
> > > warnings supressed.
> > >
> > > It seems loading pgq sets client_min_messages to warning and leaves it
> > > this way which defeats an attempt to change the setting prior and have
> > > it stick.
> > >
> > > I tested with several other extensions in same DB and only pgq has the
> > > problem.
> > >
> > > Sorry if this is known/fixed already.
> >
> > This is not part of PostgreSQL proper and thus not supported by -hackers;
> > you should report this directly to the authors.
>
> 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.

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 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.

David J.