Skip site navigation (1) Skip section navigation (2)

Re: Database bar

From: Erwin Brandstetter <brandstetter(at)falter(dot)at>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Database bar
Date: 2011-05-06 14:27:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
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?

>> 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;
> guillaume(at)postgres=# set role to toto;
> 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.
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.

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)


In response to


pgadmin-hackers by date

Next:From: pgAdmin TracDate: 2011-05-06 15:57:43
Subject: Re: [pgAdmin III] #258: Search & Replace in Query Tool trips over multibyte characters
Previous:From: Guillaume LelargeDate: 2011-05-05 20:50:11
Subject: Re: Database bar

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group