Re: Database selector

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.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com