Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbrR7-0001ZM-Ok for pgadmin-hackers@arkaria.postgresql.org; Tue, 15 Sep 2015 14:42:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZbrR7-0006oW-Al for pgadmin-hackers@arkaria.postgresql.org; Tue, 15 Sep 2015 14:42:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZbrQt-0006Zd-Hj for pgadmin-hackers@postgresql.org; Tue, 15 Sep 2015 14:42:07 +0000 Received: from mail-yk0-x235.google.com ([2607:f8b0:4002:c07::235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZbrQp-0003db-JN for pgadmin-hackers@postgresql.org; Tue, 15 Sep 2015 14:42:06 +0000 Received: by ykdu9 with SMTP id u9so188260640ykd.2 for ; Tue, 15 Sep 2015 07:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bThCLYuJtY2CVAiVCEXUFkVhAy7HdKV8jdvVZE1tG/A=; b=sfMmVxqQL1KJl6FpuRMLx5kKGDpeubobGNv5bwrMIoSCC5+yBuTES/eYh/fbVB5L8V TSm+8oZAHSk/4mUXvIr9EuagCZ+LjFCNzkwRFeWpJITpL4Y8u02LYHaA8o/zSHiTVJAx RlSzo6NssjyrP2dKwdVtBFr4CkgRYnPZg5mu4HeQNSIQP9/cjXBCV0w9toszDfRaNBuG 71N8kZ0WkRzOApbDAWWEe0ZEIh9B9ysgOiA5GGv+oT0UQNXzi59ZhgG091uFYeJ39bnM zLMl0RM4uSGO3fk3/P4A/cetq7ecJvxfoQ6rorlvrcs0E8hziNTO5YyzXNH8Nj0QJaPs 4cEw== MIME-Version: 1.0 X-Received: by 10.13.194.195 with SMTP id e186mr10022864ywd.0.1442328119870; Tue, 15 Sep 2015 07:41:59 -0700 (PDT) Received: by 10.129.115.134 with HTTP; Tue, 15 Sep 2015 07:41:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 08:41:59 -0600 Message-ID: Subject: Re: Patch: New field in frmMain statusbar From: Adam Scott To: Dave Page Cc: Magnus Hagander , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a114e6cce3c1475051fca2fa3 X-Pg-Spam-Score: -2.2 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114e6cce3c1475051fca2fa3 Content-Type: text/plain; charset=UTF-8 If you have a development host and a production host, the database names will be the same. I think the value of the having the new field goes away if you exclude the hostname. You won't know what host the object you are selecting belongs to. That could be the difference between modifying an object in development and production. It seems to me that what you could say about the display name is what could be said about the connection's display name in the tree control since this is what is displayed (plus the database name). What the patch displays answers the questions, "What connection am I on?" "What database am I on?" I guess I can work on adding another patch that allows you to customize what is displayed using frmOptions...? On Tue, Sep 15, 2015 at 5:20 AM, Dave Page wrote: > On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander > wrote: > > On Tue, Sep 15, 2015 at 10:55 AM, Dave Page wrote: > >> > >> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander > >> wrote: > >> > The part that changed is just the one that added db1 and db2, right? > >> > >> It's the server display name *and* the database name, so to give a > >> (redacted) example from my machine, I would have: > >> > >> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com (aws-ap-southeast-1b. > >> xxxxxxxxxxxxxxxx.com:5432):postgres > >> > >> Which as you can see is quite long. > > > > > > I thought the point of display names was to have them nice and short :) > I've > > certainly never used displaynames that are that long. > > I generally use the full hostnames (as I have machines in multiple > domains) - and in the places that you currently see them, that length > is actually fine. > > > Yes, I totally see with names like that it becomes annoying, and > certainly > > not easy to parse. Perhaps what we really shoul dhave is just > displayname + > > databasename, and exclude the actual hostname? > > That would be an improvement, certainly. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --001a114e6cce3c1475051fca2fa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you have a development host and a production host,= the database names will be the same.=C2=A0 I think the value of the having= the new field goes away if you exclude the hostname.=C2=A0 You won't k= now what host the object you are selecting belongs to.=C2=A0 That could be = the difference between modifying an object in development and production.= =C2=A0

It seems to me that what you could say about the = display name is what could be said about the connection's display name = in the tree control since this is what is displayed (plus the database name= ).

What the patch displays answers the questions, "W= hat connection am I on?"=C2=A0 "What database am I on?"
<= br>
I guess I can work on adding another patch that allows you to= customize what is displayed using frmOptions...?








On Tue, Sep 15, 2015 at 5:20 AM, Dave Page <dpage@p= gadmin.org> wrote:
On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Sep 15, 2015 at 10:55 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>> > The part that changed is just the one that added db1 and db2,= right?
>>
>> It's the server display name *and* the database name, so to gi= ve a
>> (redacted) example from my machine, I would have:
>>
>> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com= (aws-ap-southeast-1b.
>> xxxxxxxxxxxxxxxx.com:5432):postgres
>>
>> Which as you can see is quite long.
>
>
> I thought the point of display names was to have them nice and short := ) I've
> certainly never used displaynames that are that long.

I generally use the full hostnames (as I have machines in multiple domains) - and in the places that you currently see them, that length
is actually fine.

> Yes, I totally see with names like that it becomes annoying, and certa= inly
> not easy to parse. Perhaps what we really shoul dhave is just displayn= ame +
> databasename, and exclude the actual hostname?

That would be an improvement, certainly.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--001a114e6cce3c1475051fca2fa3--