Thread: Making SQL-pane $$ aware?
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
easierto compose SPs.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
> 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:29 PM, Josh Berkus <josh@agliodbs.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
On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <josh@agliodbs.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@agliodbs.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@agliodbs.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@agliodbs.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. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Fri, Oct 22, 2010 at 10:00 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 22/10/2010 11:50, Dave Page a écrit : >> On Fri, Oct 22, 2010 at 7:48 PM, Josh Berkus <josh@agliodbs.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...@pgadmin.org (Dave Page) wrote: > On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <j...@agliodbs.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...@pgadmin.org (Dave Page) wrote: >> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus <j...@agliodbs.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. -- Guillaumehttp://www.postgresql.frhttp://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...@pgadmin.org (Dave Page) wrote: >>> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus<j...@agliodbs.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'tsome 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...@pgadmin.org (Dave Page) wrote: >>>> On Fri, Oct 22, 2010 at 7:42 PM, Josh Berkus<j...@agliodbs.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 -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Thu, Oct 28, 2010 at 5:25 AM, Guillaume Lelarge <guillaume@lelarge.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@lelarge.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. -- Guillaumehttp://www.postgresql.frhttp://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@lelarge.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@lelarge.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@lelarge.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. -- Guillaumehttp://www.postgresql.frhttp://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@lelarge.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@lelarge.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. Connectiontool 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 definitelychanged, 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" arefilled with current values. - Pick a new server --> new values are filled in for database and user. "Database" behaves as expected: identical name asin 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@lelarge.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@lelarge.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? -- Guillaumehttp://www.postgresql.frhttp://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@lelarge.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@lelarge.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