Re: Database selector

On 11.08.2011 23:33, Guillaume Lelarge wrote:
> On Wed, 2011-08-10 at 01:50 +0200, Erwin Brandstetter wrote:
>> On 10.01.2011 04:50, Erwin Brandstetter wrote:
>>> On 06.01.2011 12:23, Guillaume Lelarge wrote:
>>>> Le 28/12/2010 20:18, Erwin Brandstetter a écrit :
>>>>> (...)
>>>>> Testing v.1.12.1 (Dec 13 2010, rev: REL-1_12_2) on Windows XP Pro, SP3
>>>>> To be sure, I downloaded the latest version and upgraded. But there
>>>>> have
>>>>> been no more changes in the meantime. Connection tool still does not
>>>>> behave as expected. I have tried with a couple of different
>>>>> databases an
>>>>> users.
>>>>>
>>>>> On a closer inspection only the field "Uername" fails. "Database" seems
>>>>> to be filled correctly. So, something has definitely changed, but half
>>>>> the fix does not seem to work as expected.
>>>>>
>>>>> Steps to reproduce:
>>>>> - Open query tool
>>>>> - Select<new connetion> from the connection tool --> popup "Connect
>>>>> to Server" appears, "Server", "Database", "User" are filled with
>>>>> current
>>>>> values.
>>>>> - Pick a new server --> new values are filled in for database and
>>>>> user.
>>>>> "Database" behaves as expected: identical name as in current
>>>>> connection if available on the new server.
>>>>> "Username" fails, however. Although a user of the same name is
>>>>> available, some other value is filled in. On the first try some
>>>>> (seemingly random) username from the list of available users is picked.
>>>>> On subsequent tries it is always the first one on the list.
>>>> I tried on 1.12.2+ and it just works. Are you sure you have the exact
>>>> same user? no odd spaces or invisible characters?
>>> I tested once more with two different sets of databases. No odd or
>>> invisible characters.
>>> Among other: username: "postgres", database: "event"
>>>
>>> In each set of databases I switched between two almost identical
>>> database clusters, the destination being a copy of the source.
>>> Results were as described above: the matching database is filled in
>>> but the username is lost in translation.
>>>
>>> Maybe someone else can run a test to add evidence? It's easy: all you
>>> need is two databases of the same name (like postgres) which share a
>>> user of the same name (like postgres) ...
>> The recent case of "pkAscending not initialized" made me think. This one
>> is just like the other: Guillaume cannot see the error I get on Windows
>> XP. Maybe another variable not initialized?
>>
> I looked into dlgSelectConnection to see if something like that could
> happen. AFAICT, it doesn't.
>
>> Testing in pgAdmin 1.14.0 Beta 3 on Win XP Pro. pg 8.4.8 and 9.0.4. I
>> tried a couple of combinations on two completely different PCs.
>> The issue is still there. I get a random pick (but the same under
>> identical circumstances) in the field "Username" where I would expect
>> the same username as in the present connection, which is available at
>> the new "server".
>>
> Could you give me your list of databases, users, and roles? the SQL
> definition would be great, but I don't need the whole databases' schema.
> Only the definition of these. Maybe I could find something with that.
>
>> This may seem unimportant, but if you use the feature a lot, switching
>> back an forth between test and productive servers with many roles, it is
>> a nuisance.
>>
> I understand. Just need a way to trigger the bug.

Thanks for looking into it, Guillaume!
I will try to build a portable testcase. This has to wait a couple of days, though.

Regards
Erwin