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-06 21:40:12
Message-ID: 4DC46ABC.5000906@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

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:
>> (...)
>>> - What if someone issues one of the following commands?
>>> RESET role;
>>> SET ROLE TO my_other_role;
>>> See for yourself:
>>> SELECT current_user, session_user;
>>> The display in the database bar remains unchanged, rendering it wrong /
>>> misleading.
>> You already have this kind of issue in 1.12 and all previous releases.
>> You connect with a user, you do "SET ROLE TO another_role", and the
>> combobox doesn't change. You could still think you're user X, but you
>> really are user another_role.
>>
>> The combobox only tells you how you established the connection, that's
>> all.
>
> Speaking of which: how about "Connection bar" instead of "Database bar"
> as title?
>

Fine to me.

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

> Firing "select current_user" each time would be an overkill for the
> purpose. I wouldn't like that. I would rather drop the feature. Typing
> "SET ROLE .." is simple enough. No need to confuse others who does not
> need it.
>

Seems good enough to be kept.

> If we need to distinguish multiple connections with the same parameters,
> just number / name the connections. In the case of names, one could name
> it after the ROLE in use - or after some other equally important criteria.
>
>
>>> Otherwise I would propose to drop it altogether to keep it safe and
>>> simple.
>>>
>> -1
>>
>>> - Also, the "database bar" is too narrow to show the whole connection
>>> string, cutting off the relevant part at the end. See attached
>>> screenshot.
>>>
>> We could make it bigger. But it won't auto-adjust, meaning there'll
>> always be someone bugged by this.
>
> From what I see under Windows, i would make it broader by maybe 15 %.
> That should cover most cases. (Not taking into account additional space
> for the active role)
>

OK.

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

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message pgAdmin Trac 2011-05-07 02:54:12 Re: [pgAdmin III] #295: Crashes with favourites in query tool
Previous Message Guillaume Lelarge 2011-05-06 21:32:52 pgAdmin III commit: Fix the activity query