Re: Patch to allow the change of the connection in the server status dialog

Le lundi 28 septembre 2009 à 12:22:12, Dave Page a écrit :
> On Sat, Sep 26, 2009 at 7:45 AM, Guillaume Lelarge
>
> <guillaume(at)lelarge(dot)info> wrote:
> > Le lundi 21 septembre 2009 à 10:04:28, Dave Page a écrit :
> >> On Sun, Sep 20, 2009 at 10:17 AM, Guillaume Lelarge
> >>
> >> <guillaume(at)lelarge(dot)info> wrote:
> >> > [...]
> >> > This patch adds a connection toolbar to the frmStatus window. It
> >> > allows one to change the connection used byt the various reports. It
> >> > is mostly important for the locks report because it's the only way to
> >> > get the name of locked relations.
> >> >
> >> > One thing that bugs me is the log report. It needs to keep the
> >> > connection to the maintenance database because it's the only database
> >> > where we require to have the adminpack functions. Should we keep two
> >> > connections (one on the maintenance database and the one selected in
> >> > the combobox)? or should we allow the change of connection for the
> >> > locks report only?
> >>
> >> I think we should use the maintenance DB as much as possible, and just
> >> use the user-selectable connection where needed.
> >
> > OK. This patch now uses only two connections: one to the maintenance DB,
> > one to a user selected one. They are the same at the beginning but can
> > change if the user selects another database. If he tries various
> > databases, each previous connection is closed before opening the new one
> > unless the previous one is the connection to the maintenance DB.
>
> OK.
>
> >> BTW - it looks like
> >> the patch as-is doesn't prevent the user from selecting an entirely
> >> different server. If the user does that (which doesn't seem entirely
> >> unreasonable), we need to switch the maintenance DB to the new server
> >> too.
> >
> > There's no more a connection toolbar. There is now a database combobox
> > available on the "standard" toolbar. It is filled at startup. Which means
> > a user cannot change his connection to an entirely different server.
>
> That seems more straightforward.
>

Thanks. Commited.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com