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-09 17:17:01
Message-ID: 4DC8218D.7040909@falter.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

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

Regards
Erwin

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2011-05-09 22:18:53 Re: First part of Luis's project for GSoC2011
Previous Message Christophe Chauvet 2011-05-07 16:43:10 1.14, Cmd +a on output grid doesn't select all lines