Re: Database selector - Mailing list pgadmin-support

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