Re: Database selector

Guys,

How tricky would it be to make the SQL pane aware of $$ escaping for
text highlighting?

Hmm. Now that I think of it, it would be good to turn this on and off.
The current lack of awareness actually makes it easier to compose SPs.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Fri, Oct 22, 2010 at 7:29 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Guys,
>
> How tricky would it be to make the SQL pane aware of $$ escaping for
> text highlighting?
>
> Hmm.  Now that I think of it, it would be good to turn this on and off.
>  The current lack of awareness actually makes it easier to compose SPs.

Pretty darn hard actually. The lexer is part of wxWidgets, and is a
generic SQL lexer. We have to write our own (probably clean-room
style, because of the licencing). I was toying with doing that anyway,
as it would be nice to have it understand plpgsql and pgscript, though
I have zero time for it unfortunately.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> Pretty darn hard actually. The lexer is part of wxWidgets, and is a
> generic SQL lexer. We have to write our own (probably clean-room
> style, because of the licencing). I was toying with doing that anyway,
> as it would be nice to have it understand plpgsql and pgscript, though
> I have zero time for it unfortunately.

OK. I don't think it's as valuable as other stuff people could be
working on. Like fixing the database selector, for example. ;-)

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Pretty darn hard actually. The lexer is part of wxWidgets, and is a
>> generic SQL lexer. We have to write our own (probably clean-room
>> style, because of the licencing). I was toying with doing that anyway,
>> as it would be nice to have it understand plpgsql and pgscript, though
>> I have zero time for it unfortunately.
>
> OK.  I don't think it's as valuable as other stuff people could be
> working on.  Like fixing the database selector, for example.  ;-)

I thought Guillaume had fixed it. Is it still borked?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> I thought Guillaume had fixed it. Is it still borked?

It is in my OSX version. Not sure what version I have installed,
because "About" is broken.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Fri, Oct 22, 2010 at 7:48 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> I thought Guillaume had fixed it. Is it still borked?
>
> It is in my OSX version.  Not sure what version I have installed,
> because "About" is broken.

:-o

What on earth did you do to it?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> What on earth did you do to it?

Just installed the 9.0 compatible version from packages. Pretty sure I
downloaded this while 9.0 was in RC.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Fri, Oct 22, 2010 at 7:54 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> What on earth did you do to it?
>
> Just installed the 9.0 compatible version from packages.  Pretty sure I
> downloaded this while 9.0 was in RC.

Our packages? In any case, please try 1.12.1.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Le 22/10/2010 11:50, Dave Page a écrit :
> On Fri, Oct 22, 2010 at 7:48 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>
>>> I thought Guillaume had fixed it. Is it still borked?
>>
>> It is in my OSX version. Not sure what version I have installed,
>> because "About" is broken.
>
> :-o
>
> What on earth did you do to it?
>

Depends on where you look at it. I mean, the about menu item in the
query tool is broken. The same in the main window is working. I should
say that I didn't use pgAdmin on Mac OS X since quite some time. When I
get back to France, I really need to make sure I can build pgAdmin on
Mac OS X again.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

On Fri, Oct 22, 2010 at 10:00 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Le 22/10/2010 11:50, Dave Page a écrit :
>> On Fri, Oct 22, 2010 at 7:48 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>>
>>>> I thought Guillaume had fixed it. Is it still borked?
>>>
>>> It is in my OSX version.  Not sure what version I have installed,
>>> because "About" is broken.
>>
>> :-o
>>
>> What on earth did you do to it?
>>
>
> Depends on where you look at it. I mean, the about menu item in the
> query tool is broken. The same in the main window is working. I should
> say that I didn't use pgAdmin on Mac OS X since quite some time. When I
> get back to France, I really need to make sure I can build pgAdmin on
> Mac OS X again.

Oh, grrr. That's OSX adding menu options on it's own. We don't include
About except on the main form. I guess we'll need to add it.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Oct 22, 8:45 pm, dp(dot)(dot)(dot)(at)pgadmin(dot)org (Dave Page) wrote:
> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <j(dot)(dot)(dot)(at)agliodbs(dot)com> wrote:
>
> >> Pretty darn hard actually. The lexer is part of wxWidgets, and is a
> >> generic SQL lexer. We have to write our own (probably clean-room
> >> style, because of the licencing). I was toying with doing that anyway,
> >> as it would be nice to have it understand plpgsql and pgscript, though
> >> I have zero time for it unfortunately.
>
> > OK.  I don't think it's as valuable as other stuff people could be
> > working on.  Like fixing the database selector, for example.  ;-)
>
> I thought Guillaume had fixed it. Is it still borked?

If you talk about ticket #232 "Smart defaults for new connection in
query tool" I may be able to shed some light on that as I brought that
up in the first place.
Guillaume wrote a fix, and it looks good, but for an unknown reason it
has been reserved for v1.14. (It certainly is not in the current
version.)
Or did you mean something else entirely?

Regards
Erwin

Le 26/10/2010 17:11, Erwin Brandstetter a écrit :
> On Oct 22, 8:45 pm, dp(dot)(dot)(dot)(at)pgadmin(dot)org (Dave Page) wrote:
>> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <j(dot)(dot)(dot)(at)agliodbs(dot)com> wrote:
>>
>>>> Pretty darn hard actually. The lexer is part of wxWidgets, and is a
>>>> generic SQL lexer. We have to write our own (probably clean-room
>>>> style, because of the licencing). I was toying with doing that anyway,
>>>> as it would be nice to have it understand plpgsql and pgscript, though
>>>> I have zero time for it unfortunately.
>>
>>> OK. I don't think it's as valuable as other stuff people could be
>>> working on. Like fixing the database selector, for example. ;-)
>>
>> I thought Guillaume had fixed it. Is it still borked?
>
> If you talk about ticket #232 "Smart defaults for new connection in
> query tool" I may be able to shed some light on that as I brought that
> up in the first place.
> Guillaume wrote a fix, and it looks good, but for an unknown reason it
> has been reserved for v1.14. (It certainly is not in the current
> version.)

I commited it only on the master branch because this is not a bugfix.
It's a new behaviour on something that works, hence it's in the dev branch.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

On 27.10.2010 17:51, Guillaume Lelarge wrote:
> Le 26/10/2010 17:11, Erwin Brandstetter a écrit :
>> On Oct 22, 8:45 pm, dp(dot)(dot)(dot)(at)pgadmin(dot)org (Dave Page) wrote:
>>> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus<j(dot)(dot)(dot)(at)agliodbs(dot)com> wrote:
>>> (...)
>>>> OK. I don't think it's as valuable as other stuff people could be
>>>> working on. Like fixing the database selector, for example. ;-)
>>> I thought Guillaume had fixed it. Is it still borked?
>> If you talk about ticket #232 "Smart defaults for new connection in
>> query tool" I may be able to shed some light on that as I brought that
>> up in the first place.
>> Guillaume wrote a fix, and it looks good, but for an unknown reason it
>> has been reserved for v1.14. (It certainly is not in the current
>> version.)
> I commited it only on the master branch because this is not a bugfix.
> It's a new behaviour on something that works, hence it's in the dev branch.

As far as I am concerned, it would be welcome as bugfix in 1.12, as the present behaviour is a nuisance. Given there wasn't some misunderstanding,
Josh felt the same way.
But your mileage may vary ...

Regards
Erwin

Le 27/10/2010 10:12, Erwin Brandstetter a écrit :
> On 27.10.2010 17:51, Guillaume Lelarge wrote:
>> Le 26/10/2010 17:11, Erwin Brandstetter a écrit :
>>> On Oct 22, 8:45 pm, dp(dot)(dot)(dot)(at)pgadmin(dot)org (Dave Page) wrote:
>>>> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus<j(dot)(dot)(dot)(at)agliodbs(dot)com> wrote:
>>>> (...)
>>>>> OK. I don't think it's as valuable as other stuff people could be
>>>>> working on. Like fixing the database selector, for example. ;-)
>>>> I thought Guillaume had fixed it. Is it still borked?
>>> If you talk about ticket #232 "Smart defaults for new connection in
>>> query tool" I may be able to shed some light on that as I brought that
>>> up in the first place.
>>> Guillaume wrote a fix, and it looks good, but for an unknown reason it
>>> has been reserved for v1.14. (It certainly is not in the current
>>> version.)
>> I commited it only on the master branch because this is not a bugfix.
>> It's a new behaviour on something that works, hence it's in the dev
>> branch.
>
> As far as I am concerned, it would be welcome as bugfix in 1.12, as the
> present behaviour is a nuisance. Given there wasn't some
> misunderstanding, Josh felt the same way.
> But your mileage may vary ...
>

Dave, Magnus, any opinion on this?

It sure isn't a lot of code, and one can think it is a bugfix. Not
really my opinion, but I don't object to apply it on 1.12.

FYI:
http://code.pgadmin.org/trac/ticket/232

http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Dave, Magnus, any opinion on this?
>
> It sure isn't a lot of code, and one can think it is a bugfix. Not
> really my opinion, but I don't object to apply it on 1.12.
>
> FYI:
>  http://code.pgadmin.org/trac/ticket/232
>
> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa

I think we can consider it a bug. It may not actually be a crash or
anything, but it's certainly a UI design issue.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Le 28/10/2010 00:33, Dave Page a écrit :
> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
>> Dave, Magnus, any opinion on this?
>>
>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>> really my opinion, but I don't object to apply it on 1.12.
>>
>> FYI:
>> http://code.pgadmin.org/trac/ticket/232
>>
>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>
> I think we can consider it a bug. It may not actually be a crash or
> anything, but it's certainly a UI design issue.
>

Done.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

On 29.10.2010 08:21, Guillaume Lelarge wrote:
> Le 28/10/2010 00:33, Dave Page a écrit :
>> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>>> Dave, Magnus, any opinion on this?
>>>
>>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>>> really my opinion, but I don't object to apply it on 1.12.
>>>
>>> FYI:
>>> http://code.pgadmin.org/trac/ticket/232
>>>
>>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>> I think we can consider it a bug. It may not actually be a crash or
>> anything, but it's certainly a UI design issue.
>>
> Done.

I did some checks on fixes for 1.12.2 and found that this does not seem to be in the new version .. ?

Regards
Erwin

Le 28/12/2010 18:41, Erwin Brandstetter a écrit :
> On 29.10.2010 08:21, Guillaume Lelarge wrote:
>> Le 28/10/2010 00:33, Dave Page a écrit :
>>> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
>>> <guillaume(at)lelarge(dot)info> wrote:
>>>> Dave, Magnus, any opinion on this?
>>>>
>>>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>>>> really my opinion, but I don't object to apply it on 1.12.
>>>>
>>>> FYI:
>>>> http://code.pgadmin.org/trac/ticket/232
>>>>
>>>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>>>>
>>> I think we can consider it a bug. It may not actually be a crash or
>>> anything, but it's certainly a UI design issue.
>>>
>> Done.
>
> I did some checks on fixes for 1.12.2 and found that this does not seem
> to be in the new version .. ?
>

It should be. It is in the CHANGELOG:

2010-10-28 GL 1.12.2 Select old values when connecting to another server.

and on git:

commit 9cb216f9a67838e041e65fd0f9fead425cdfe8b1
Author: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Date: Thu Sep 9 23:26:23 2010 +0200

Select old values when connecting to another server

When a user selects another server, the database and user comboboxes are
cleared and filled again with the new values. The last selected item
for both
comboboxes should be selected if they are still present.

Fixes #232.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

On 28.12.2010 19:01, Guillaume Lelarge wrote:
> Le 28/12/2010 18:41, Erwin Brandstetter a écrit :
>> On 29.10.2010 08:21, Guillaume Lelarge wrote:
>>> Le 28/10/2010 00:33, Dave Page a écrit :
>>>> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
>>>> <guillaume(at)lelarge(dot)info> wrote:
>>>>> Dave, Magnus, any opinion on this?
>>>>>
>>>>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>>>>> really my opinion, but I don't object to apply it on 1.12.
>>>>>
>>>>> FYI:
>>>>> http://code.pgadmin.org/trac/ticket/232
>>>>>
>>>>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>>>>>
>>>> I think we can consider it a bug. It may not actually be a crash or
>>>> anything, but it's certainly a UI design issue.
>>>>
>>> Done.
>> I did some checks on fixes for 1.12.2 and found that this does not seem
>> to be in the new version .. ?
>>
> It should be. It is in the CHANGELOG:
>
> 2010-10-28 GL 1.12.2 Select old values when connecting to another server.
>
> and on git:
>
> commit 9cb216f9a67838e041e65fd0f9fead425cdfe8b1
> Author: Guillaume Lelarge<guillaume(at)lelarge(dot)info>
> Date: Thu Sep 9 23:26:23 2010 +0200
>
> Select old values when connecting to another server
>
> When a user selects another server, the database and user comboboxes are
> cleared and filled again with the new values. The last selected item
> for both
> comboboxes should be selected if they are still present.
>
> Fixes #232.

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.

Regards
Erwin

Le 28/12/2010 20:18, Erwin Brandstetter a écrit :
> On 28.12.2010 19:01, Guillaume Lelarge wrote:
>> Le 28/12/2010 18:41, Erwin Brandstetter a écrit :
>>> On 29.10.2010 08:21, Guillaume Lelarge wrote:
>>>> Le 28/10/2010 00:33, Dave Page a écrit :
>>>>> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
>>>>> <guillaume(at)lelarge(dot)info> wrote:
>>>>>> Dave, Magnus, any opinion on this?
>>>>>>
>>>>>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>>>>>> really my opinion, but I don't object to apply it on 1.12.
>>>>>>
>>>>>> FYI:
>>>>>> http://code.pgadmin.org/trac/ticket/232
>>>>>>
>>>>>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>>>>>>
>>>>>>
>>>>> I think we can consider it a bug. It may not actually be a crash or
>>>>> anything, but it's certainly a UI design issue.
>>>>>
>>>> Done.
>>> I did some checks on fixes for 1.12.2 and found that this does not seem
>>> to be in the new version .. ?
>>>
>> It should be. It is in the CHANGELOG:
>>
>> 2010-10-28 GL 1.12.2 Select old values when connecting to another
>> server.
>>
>> and on git:
>>
>> commit 9cb216f9a67838e041e65fd0f9fead425cdfe8b1
>> Author: Guillaume Lelarge<guillaume(at)lelarge(dot)info>
>> Date: Thu Sep 9 23:26:23 2010 +0200
>>
>> Select old values when connecting to another server
>>
>> When a user selects another server, the database and user
>> comboboxes are
>> cleared and filled again with the new values. The last selected item
>> for both
>> comboboxes should be selected if they are still present.
>>
>> Fixes #232.
>
> 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?

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

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) ...

Regards
Erwin

On 06.01.2011 12:23, Guillaume Lelarge wrote:
> Le 28/12/2010 20:18, Erwin Brandstetter a écrit :
>> On 28.12.2010 19:01, Guillaume Lelarge wrote:
>>> Le 28/12/2010 18:41, Erwin Brandstetter a écrit :
>>>> On 29.10.2010 08:21, Guillaume Lelarge wrote:
>>>>> Le 28/10/2010 00:33, Dave Page a écrit :
>>>>>> On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge
>>>>>> <guillaume(at)lelarge(dot)info> wrote:
>>>>>>> Dave, Magnus, any opinion on this?
>>>>>>>
>>>>>>> It sure isn't a lot of code, and one can think it is a bugfix. Not
>>>>>>> really my opinion, but I don't object to apply it on 1.12.
>>>>>>>
>>>>>>> FYI:
>>>>>>> http://code.pgadmin.org/trac/ticket/232
>>>>>>>
>>>>>>> http://github.com/gleu/pgadmin3/commit/8c358a7ead668bc7b2f7c845ab83b4b3c8f4d1aa
>>>>>>>
>>>>>>>
>>>>>> I think we can consider it a bug. It may not actually be a crash or
>>>>>> anything, but it's certainly a UI design issue.
>>>>>>
>>>>> Done.
>>>> I did some checks on fixes for 1.12.2 and found that this does not seem
>>>> to be in the new version .. ?
>>>>
>>> It should be. It is in the CHANGELOG:
>>>
>>> 2010-10-28 GL 1.12.2 Select old values when connecting to another
>>> server.
>>>
>>> and on git:
>>>
>>> commit 9cb216f9a67838e041e65fd0f9fead425cdfe8b1
>>> Author: Guillaume Lelarge<guillaume(at)lelarge(dot)info>
>>> Date: Thu Sep 9 23:26:23 2010 +0200
>>>
>>> Select old values when connecting to another server
>>>
>>> When a user selects another server, the database and user
>>> comboboxes are
>>> cleared and filled again with the new values. The last selected item
>>> for both
>>> comboboxes should be selected if they are still present.
>>>
>>> Fixes #232.
>> Testing v.1.12.1 (Dec 13 2010, rev: REL-1_12_2) on Windows XP Pro, SP3
BTW, this is a typo, I tested with 1.12.2, as the rest of the string
indicates ...

Regards
Erwin

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?

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".

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.

Regards
Erwin

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

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

On Fri, 2011-08-12 at 16:20 +0200, Erwin Brandstetter wrote:
> 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.
>

No problem. Send it when you're ready.

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