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

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: (view raw, whole thread or download thread mbox)
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;
>> 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)



In response to


pgadmin-hackers by date

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

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