Re: Database bar

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Erwin Brandstetter <brandstetter(at)falter(dot)at>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Database bar
Date: 2011-05-28 13:56:58
Message-ID: 4DE0FF2A.9000408@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On 05/09/2011 07:17 PM, Erwin Brandstetter wrote:
> On 06.05.2011 23:40, Guillaume Lelarge wrote:
>> On 05/06/2011 04:27 PM, Erwin Brandstetter wrote:
>>> Hi Guillaume!
>>>
>>> On 05.05.2011 22:50, Guillaume Lelarge wrote:
>>>> On 05/05/2011 05:25 PM, Erwin Brandstetter wrote:
>>>> (...)
>>>>> Changing to another connection and changing back does not change the
>>>>> situation.
>>>> Meaning?
>>> One might expect, that by chosing a connection named "mydb on
>>> myuser(at)myserver:port ~myrole" the role would be set as advertised. But
>>> that's not how it works. (And I am not saying it should.)
>>> I don't have a strong opinion here. My reasoning is this:
>>> - pgAdmin is getting increasingly complex.
>>> - Therefore, if a feature is of limited use while introducing chances
>>> for errors and misunderstandings, we should consider not having it at
>>> all.
>>> If there is use cases where the feature helps a lot, my reasoning is
>>> moot.
>>>
>>>
>>>>> This could get quite hazardous. Imagine a command in the mistaken
>>>>> belief
>>>>> it would be executed by the displayed role ...
>>>>>
>>>> As I said, it could already happen in 1.12.
>>>>> If we keep this functionality the database bar would have to show the
>>>>> currently active role IMHO.
>>>> No, I won't add a parser to know if the user tried to do a "SET ROLE
>>>> TO".
>>>>
>>>> BTW, psql does the same as us:
>>>>
>>>> guillaume(at)postgres=# create user toto;
>>>> CREATE ROLE
>>>> guillaume(at)postgres=# set role to toto;
>>>> SET
>>>> guillaume(at)postgres=>
>>>>
>>>> See the prompt? it doesn't say toto(at)postgres(dot) Quite misleading, uh? :)
>>>>
>>>> Honestly, I think you're right that it's misleading and I would
>>>> agree to
>>>> add a panel to the status bar to say who's the actual role. But it
>>>> means
>>>> we will fire a "select current_user;" each time the user executes a
>>>> query or a group of queries. Not sure everyone would like that.
>>> To be precise: up to 1.12 the "Database bar" only displays information
>>> about the _connection_. This is always true, even after SET ROLE.
>>> So does psql.
>>> In 1.14 information about the _active role_ is added. But this can be
>>> false.
>> So, one solution would be to get rid of the role name in the connection
>> combo box. Would you be happy with that solution?
>
> I have given it some thought over the weekend, but there is no clean way
> around it. If the active role is advertised in the connection bar, then
> it should be the _actually_ active role. Therefore, your proposal to
> fire "select current_user;" after every executed piece of code is the
> proper way. (You would not do that for connections that have been
> started without SET ROLE.)
> (I would still drop the feature. It adds complexity and I don't see the
> need.)
>
> Not displaying the active role might be a compromise to avoid the
> overhead as well as false advertising.
> But then: how to distinguish between several connections? You keep them
> in the order of their appearance, but most people will not realize that.
> Also I am not sure if that is guaranteed. How about assigning sequential
> numbers? Does not need much space and would help to identify /
> distinguish connections - epecially if the connection string gets
> truncated or if one opens multiple connections to the same DB.
>
> 1: mydb on myuser(at)myserver:port
> 2: myotherdb on myuser(at)myotherserver:port
> 3: mydb on myuser(at)myserver:port
>

So, I finally did some fixes:

* "Database bar" has been renamed to "Connection bar".
* The connection bar is larger. (check if it is enough, it's quite hard
to be sure of it)
* The connection name doesn't contain the rolename.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Vladimir Kokovic 2011-05-28 15:06:43 Table dependents tab empty lines
Previous Message Guillaume Lelarge 2011-05-28 13:55:40 pgAdmin III commit: Some fixes on the query tool