Re: [pgadmin-hackers] Query tool: Autocompletion
Thanks - applied. /D On 31/1/06 19:46, "Magnus Hagander" <[EMAIL PROTECTED]> wrote: >> - select * from pg_c> However, the popup will show the same problem as on Windows, >> remaining on top of all windows. > > This patch fixes the problem on Windows. Don't have a linux box around > to test there, sorry. The patch is simple enough, I think it *should* > work... > > //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] Query tool: Autocompletion
> - select * from pg_c However, the popup will show the same problem as on Windows, > remaining on top of all windows. This patch fixes the problem on Windows. Don't have a linux box around to test there, sorry. The patch is simple enough, I think it *should* work... //Magnus autocomplete_popup.patch Description: autocomplete_popup.patch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Query tool: Autocompletion
> - On Linux, pg_cast will appear instead of the popup. Doesn't happen for me. I get the full popup. > - On Linux, every will insert two \n, i.e. an > additional empty line that can't be addressed with the > cursor. This is also true if autotabcomplete is disabled > (doesn't happen when reading a script from a file). I see yuo're working on this one already. (Yeah, I pulled a new svn during the time it was broken :P) It appears to fix the problem for me on linux. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: Thanks, patch applied with minor tweaking re: trailing spaces as discussed on IM, and documentation. More problems on Linux: - select * from pg_cpopup will show the same problem as on Windows, remaining on top of all windows. - All ctrl keys were executed twice, fixed in svn. Still, I'm not sure if event.m_metaDown=false shouldn't be active for OSX too. It has effect on function keys (F5 et al) - SELECT * FROM pg_class, pg_att won't do anything. - SELECT * FROM pg_class, pg_attribute WHERE will deliver pg_attribute columns only. - SELECT * FROM pg_class JOIN pg_attribute ON won't do anything. This renders the feature nearly useless. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: Thanks, patch applied with minor tweaking re: trailing spaces as discussed on IM, and documentation. I eyeballed the multibyte handling, it looks ok to me. But I found some nasty misbehaviours: select * from pg_c - On Windows, a popup will appear. If you activate a different app (e.g. the debugger which runs pgadmin), it will stay on top. Only selecting the very ctlSqlBox window will let it disappear (this is the usual popup window fun...) - On Linux, pg_cast will appear instead of the popup. - On Linux, every will insert two \n, i.e. an additional empty line that can't be addressed with the cursor. This is also true if autotabcomplete is disabled (doesn't happen when reading a script from a file). Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query tool: Autocompletion
Thanks, patch applied with minor tweaking re: trailing spaces as discussed on IM, and documentation. Regards, Dave. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: 08 January 2006 15:05 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Query tool: Autocompletion > > Dave tells me the list silently eats large mails, so here is the mail > again without the patch. The patch is now on > http://www.hagander.net/pgsql/patches/pgadmin_autocomplete.patch > > //Magnus > > > > -Original Message- > > From: Magnus Hagander > > Sent: Saturday, January 07, 2006 6:33 PM > > To: pgadmin-hackers@postgresql.org > > Subject: Query tool: Autocompletion > > > > Hi! > > > > Attached is a first attempt at autocompletion for the SQL > > Query tool. It probably needs some more work, but it's a start :-) > > > > It's based on the tab completion in psql. The idea is to pull > > the latest and greatest tab-complete.c from psql, then run it > > through a perlscript that picks out the tasty parts. > > > > > > Anyway. Attached is the patch. I've also included a > > tab-complete.inc from the current Due to a bug in the Visual > > C++ compiler, it *has* to be compiled as "C" not as "C++". > > Thus, a bit if ugly glue is required between those two worlds > > :-)psql - to make it build directly (without adding a build > > dependency on perl), this one is what should probably go in > > svn, and then be manually sycned onw and then from psql. > > "tabcomplete.c" needs to be added to the build project (I'm > > devving in Visual Studio 2003, so I can't modify the .dsw > > from there easily). > > > > I've only tested this on Windows so far. Wouldn't surprise me > > if some minor work is needed to build on *nix. > > > > I'm also unsure if I can get away with the easy way I pass > > strings in and out of wx (encoding issues?). It works in my > > testcases, but I'm not familiar enough to be sure if it > always does. > > > > Finally, I've added a screenshot for those who don't want to > > rebuild :) > > > > So. Thoughts, and comments? > > > > //Magnus > > > > ---(end of > broadcast)--- > TIP 5: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query tool: Autocompletion
> > >>I've spent several hours now to get the beast compiled, > > still no go. > > >>It's a nightmare I don't like to spend more time on. > > > > > > > > > Hmm, I got it going in 5 minutes in VC6. Works quite well. > > > > Not in Linux. > > Due to the longer building times, yes, it tok longer on > linux. And I hadn't tested it. But it certainly didn't take > more than 5-10 minutes active time ;-) > > Attached is an updated patch that compiles fine on linux (on > developer.pgadmin.org), and works (only did minor tests). > I've also included a pre-generated .inc file. I did not move > any files. > > The #ifdefs are perhaps better handled with autoconf macros, > haven't investigated that yet - I just wanted to get > somethign out that you can test with on linux quickly. Oops. Didn't do "svn add" on the linux box, so it was missing the file that actually had the changes (except for the makefile).Here it is. (tab-complete.pl unchanged from previous patch) //Magnus tabcomplete.c Description: tabcomplete.c ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool: Autocompletion
> -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: 26 January 2006 11:37 > To: Dave Page; Andreas Pflug > Cc: pgadmin-hackers@postgresql.org > Subject: RE: [pgadmin-hackers] Query tool: Autocompletion > > > > Don't know enough about the classes to really comment. They > > can't be > > > built on-demand somehow? > > > > Yeah, but my point is that typing in the query tool might > > trigger a DB connect followed by a deep build of the tree > > which might be very expensive. That might outweigh the > > benefits of using the cache. > > Right. But couldn't you have it not do a deep build, but a > shallow one? > So when I hit (or whatever) where it wants a table > name, you build > the list of tables *only*. Or use the cache when you have it. > Then wheni > t wants attributes for "table a", you build the cache of that. Yeah, that is as far as it needs to go, but down to table level is deep enough. For example, the standard connect and restore goes to that level, and in a quick test here that took about 13 seconds for borg.postgresql.org. Using the pre-existing connection is definitely going to be far faster than that kind of unnacceptable delay. > If you really need the cache. I'm not sure the cost is so big, I've > never had problems with psql and I use tab completion all the time > there... Though most of my dbs don't have a huge amount of tables, it > might be a problem then I guess. > > BTW, I also have this notion of being able to run *just* the query > editor (not just start pgadmin and open the query editor, but never > actually build the tree and stuff when I know I'm not going > to need it). > Not sure if others want that as well, or what effect it would have on > something like this, just wanted to point it out :) I could very often do with that capability. I'm more or less convinced that the current patch is the optimal approach overall. Regards, Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query tool: Autocompletion
> > Don't know enough about the classes to really comment. They > can't be > > built on-demand somehow? > > Yeah, but my point is that typing in the query tool might > trigger a DB connect followed by a deep build of the tree > which might be very expensive. That might outweigh the > benefits of using the cache. Right. But couldn't you have it not do a deep build, but a shallow one? So when I hit (or whatever) where it wants a table name, you build the list of tables *only*. Or use the cache when you have it. Then wheni t wants attributes for "table a", you build the cache of that. If you really need the cache. I'm not sure the cost is so big, I've never had problems with psql and I use tab completion all the time there... Though most of my dbs don't have a huge amount of tables, it might be a problem then I guess. BTW, I also have this notion of being able to run *just* the query editor (not just start pgadmin and open the query editor, but never actually build the tree and stuff when I know I'm not going to need it). Not sure if others want that as well, or what effect it would have on something like this, just wanted to point it out :) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query tool: Autocompletion
> -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: 26 January 2006 10:04 > To: Dave Page; Andreas Pflug > Cc: pgadmin-hackers@postgresql.org > Subject: RE: [pgadmin-hackers] Query tool: Autocompletion > > Don't know enough about the classes to really comment. They can't be > built on-demand somehow? Yeah, but my point is that typing in the query tool might trigger a DB connect followed by a deep build of the tree which might be very expensive. That might outweigh the benefits of using the cache. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query tool: Autocompletion
> > I've spent several hours now to get the beast compiled, > still no go. > > It's a nightmare I don't like to spend more time on. > > Hmm, I got it going in 5 minutes in VC6. Works quite well. That's about how long it took me as well to apply it to a different machine and run there. Only done it in VS, though. > > Dave, if you succeed hacking something workable that doesn't try to > > call more core pgsql includes from somewhere (!), commit it. Note: > > pgsql copied stuff should go to src/db, not utils. > > Well, I can certainly commit what's there fairly quickly. > > > Actually, I doubt that the psql way is desirable at all. Instead of > > constantly accessing the db for completion candidates, > using pgAdmin's > > object tree as cache should be the way to go. > > That's a good point. Magnus, any thoughts on doing it that way? > Shouldn't be too hard to swap out the queries for scans of the tree. Well, it kind of takes out the whole idea of using psql. The queries are one of the main things that we pull in from psql. That means we rewrite the matching logic, and if we do that, we should just skip the whole idea of pulling it in from psql. Which also means we need to maintain it separatly, the avoidance of which was one of the main reasons I looked at stealing-from-psql as a solution. But it certainly *can* be done. Though I think it's more work than "not too hard". > Mind you, the downside of that is that tab complete would > essentially have to build large chunks of the tree on > databases that might not even be connected in response to > random typing in the query tool. Whilst it seems a nice idea > to use the tree objects as a cache, it could have some pretty > nasty side effects. Don't know enough about the classes to really comment. They can't be built on-demand somehow? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 26 January 2006 00:06 To: Magnus Hagander Cc: Dave Page; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query tool: Autocompletion I've spent several hours now to get the beast compiled, still no go. It's a nightmare I don't like to spend more time on. Hmm, I got it going in 5 minutes in VC6. Works quite well. Not in Linux. Regards, Andreas ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] Query tool: Autocompletion
> -Original Message- > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > Sent: 26 January 2006 00:06 > To: Magnus Hagander > Cc: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Query tool: Autocompletion > > I've spent several hours now to get the beast compiled, still no go. > It's a nightmare I don't like to spend more time on. Hmm, I got it going in 5 minutes in VC6. Works quite well. > Dave, if you succeed hacking something workable that doesn't > try to call > more core pgsql includes from somewhere (!), commit it. Note: pgsql > copied stuff should go to src/db, not utils. Well, I can certainly commit what's there fairly quickly. > Actually, I doubt that the psql way is desirable at all. Instead of > constantly accessing the db for completion candidates, using > pgAdmin's > object tree as cache should be the way to go. That's a good point. Magnus, any thoughts on doing it that way? Shouldn't be too hard to swap out the queries for scans of the tree. Mind you, the downside of that is that tab complete would essentially have to build large chunks of the tree on databases that might not even be connected in response to random typing in the query tool. Whilst it seems a nice idea to use the tree objects as a cache, it could have some pretty nasty side effects. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query tool: Autocompletion
I've spent several hours now to get the beast compiled, still no go. It's a nightmare I don't like to spend more time on. Dave, if you succeed hacking something workable that doesn't try to call more core pgsql includes from somewhere (!), commit it. Note: pgsql copied stuff should go to src/db, not utils. Actually, I doubt that the psql way is desirable at all. Instead of constantly accessing the db for completion candidates, using pgAdmin's object tree as cache should be the way to go. Regards, Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: Andreas; have you had a chance to look at this yet? No, not yet. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Query tool: Autocompletion
Andreas; have you had a chance to look at this yet? Regards, Dave. > -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: 15 January 2006 17:30 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: RE: [pgadmin-hackers] Query tool: Autocompletion > > > > > So. Thoughts, and comments? > > > > Nice, it works quite well. Some thoughts: > > Here's an updated version. No change in the actual "psql-emulation" > logic, so no new .inc file needed. > > > > - My main concern is that I do use tab, which this prevents - > > as per your comment in the source I think we need an option > > to turn the feature off for those that don't want it. > > Config option added in this one. I left it always possible to use > Ctrl-Space to do it (visual studio style). I don't think anybody > actually uses Ctrl-Space in their SQL code, but I'm sure a lot of ppl > use TAB. > > > > - A space should be added after an item has been inserted > > form the auto-complete list, per psql. > > Done in this version. If you "terminate" the popdown using space, you > end up with *two* spaces. From what I can tell, there is no way around > that. And two spaces shouldn't break a query. > > > > - Schema-prefixed table names can't have columns in the WHERE > > clause auto-completed. Actually on further investigation this > > seems to apply to psql as well. > > It does. I think I saw something on the list that someone was > working on > making the tab completion better in psql. I'm not sure if this is part > of it though. > (Though I'm sure this patch will have to be updated once that is > applied, since it looked like one or two renames of macros etc) > > > > - SELECT * FROM foo WHERE bar = 'FOO' AND doesn't work. > > Also as per psql? > > Yes. > > > > I'd like Andreas to look at this before applying - > > particularly the encoding bits which are still largely a > > mystery to me as well. > > Sounds good. > > > //Magnus > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] Query tool: Autocompletion
> > I'd like Andreas to look at this before applying - particularly the > > encoding bits which are still largely a mystery to me as well. > > Um, nicely spoken :-) > I'll have a tight look at it, esp. the disable option. I'd be > positively surprised if the feature can cope with my less > than straight forward editing habits. Welcome back, hope you had a good holiday! Note that the idea is to have "simple tab-complete". As long as it doesn't *break* your stuff, don't expect it to always show a popup menu ;-) It's a start, we can always improve it later - by updating the one in psql ;-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 08 January 2006 15:05 To: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query tool: Autocompletion Attached is a first attempt at autocompletion for the SQL Query tool. It probably needs some more work, but it's a start :-) It's based on the tab completion in psql. The idea is to pull the latest and greatest tab-complete.c from psql, then run it through a perlscript that picks out the tasty parts. Anyway. Attached is the patch. I've also included a tab-complete.inc from the current Due to a bug in the Visual C++ compiler, it *has* to be compiled as "C" not as "C++". Thus, a bit if ugly glue is required between those two worlds :-)psql - to make it build directly (without adding a build dependency on perl), this one is what should probably go in svn, and then be manually sycned onw and then from psql. "tabcomplete.c" needs to be added to the build project (I'm devving in Visual Studio 2003, so I can't modify the .dsw from there easily). I've only tested this on Windows so far. Wouldn't surprise me if some minor work is needed to build on *nix. I'm also unsure if I can get away with the easy way I pass strings in and out of wx (encoding issues?). It works in my testcases, but I'm not familiar enough to be sure if it always does. Finally, I've added a screenshot for those who don't want to rebuild :) So. Thoughts, and comments? Nice, it works quite well. Some thoughts: - My main concern is that I do use tab, which this prevents - as per your comment in the source I think we need an option to turn the feature off for those that don't want it. - A space should be added after an item has been inserted form the auto-complete list, per psql. - Schema-prefixed table names can't have columns in the WHERE clause auto-completed. Actually on further investigation this seems to apply to psql as well. - SELECT * FROM foo WHERE bar = 'FOO' AND doesn't work. Also as per psql? I'd like Andreas to look at this before applying - particularly the encoding bits which are still largely a mystery to me as well. Um, nicely spoken :-) I'll have a tight look at it, esp. the disable option. I'd be positively surprised if the feature can cope with my less than straight forward editing habits. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query tool: Autocompletion
> > > So. Thoughts, and comments? > > Nice, it works quite well. Some thoughts: Here's an updated version. No change in the actual "psql-emulation" logic, so no new .inc file needed. > - My main concern is that I do use tab, which this prevents - > as per your comment in the source I think we need an option > to turn the feature off for those that don't want it. Config option added in this one. I left it always possible to use Ctrl-Space to do it (visual studio style). I don't think anybody actually uses Ctrl-Space in their SQL code, but I'm sure a lot of ppl use TAB. > - A space should be added after an item has been inserted > form the auto-complete list, per psql. Done in this version. If you "terminate" the popdown using space, you end up with *two* spaces. From what I can tell, there is no way around that. And two spaces shouldn't break a query. > - Schema-prefixed table names can't have columns in the WHERE > clause auto-completed. Actually on further investigation this > seems to apply to psql as well. It does. I think I saw something on the list that someone was working on making the tab completion better in psql. I'm not sure if this is part of it though. (Though I'm sure this patch will have to be updated once that is applied, since it looked like one or two renames of macros etc) > - SELECT * FROM foo WHERE bar = 'FOO' AND doesn't work. > Also as per psql? Yes. > I'd like Andreas to look at this before applying - > particularly the encoding bits which are still largely a > mystery to me as well. Sounds good. //Magnus pgadmin_autocomplete2.patch Description: pgadmin_autocomplete2.patch ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool: Autocompletion
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: 08 January 2006 15:05 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Query tool: Autocompletion > > > Attached is a first attempt at autocompletion for the SQL > > Query tool. It probably needs some more work, but it's a start :-) > > > > It's based on the tab completion in psql. The idea is to pull > > the latest and greatest tab-complete.c from psql, then run it > > through a perlscript that picks out the tasty parts. > > > > > > Anyway. Attached is the patch. I've also included a > > tab-complete.inc from the current Due to a bug in the Visual > > C++ compiler, it *has* to be compiled as "C" not as "C++". > > Thus, a bit if ugly glue is required between those two worlds > > :-)psql - to make it build directly (without adding a build > > dependency on perl), this one is what should probably go in > > svn, and then be manually sycned onw and then from psql. > > "tabcomplete.c" needs to be added to the build project (I'm > > devving in Visual Studio 2003, so I can't modify the .dsw > > from there easily). > > > > I've only tested this on Windows so far. Wouldn't surprise me > > if some minor work is needed to build on *nix. > > > > I'm also unsure if I can get away with the easy way I pass > > strings in and out of wx (encoding issues?). It works in my > > testcases, but I'm not familiar enough to be sure if it > always does. > > > > Finally, I've added a screenshot for those who don't want to > > rebuild :) > > > > So. Thoughts, and comments? Nice, it works quite well. Some thoughts: - My main concern is that I do use tab, which this prevents - as per your comment in the source I think we need an option to turn the feature off for those that don't want it. - A space should be added after an item has been inserted form the auto-complete list, per psql. - Schema-prefixed table names can't have columns in the WHERE clause auto-completed. Actually on further investigation this seems to apply to psql as well. - SELECT * FROM foo WHERE bar = 'FOO' AND doesn't work. Also as per psql? I'd like Andreas to look at this before applying - particularly the encoding bits which are still largely a mystery to me as well. Regards, Dave. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave tells me the list silently eats large mails, so here is the mail again without the patch. The patch is now on http://www.hagander.net/pgsql/patches/pgadmin_autocomplete.patch //Magnus > -Original Message- > From: Magnus Hagander > Sent: Saturday, January 07, 2006 6:33 PM > To: pgadmin-hackers@postgresql.org > Subject: Query tool: Autocompletion > > Hi! > > Attached is a first attempt at autocompletion for the SQL > Query tool. It probably needs some more work, but it's a start :-) > > It's based on the tab completion in psql. The idea is to pull > the latest and greatest tab-complete.c from psql, then run it > through a perlscript that picks out the tasty parts. > > > Anyway. Attached is the patch. I've also included a > tab-complete.inc from the current Due to a bug in the Visual > C++ compiler, it *has* to be compiled as "C" not as "C++". > Thus, a bit if ugly glue is required between those two worlds > :-)psql - to make it build directly (without adding a build > dependency on perl), this one is what should probably go in > svn, and then be manually sycned onw and then from psql. > "tabcomplete.c" needs to be added to the build project (I'm > devving in Visual Studio 2003, so I can't modify the .dsw > from there easily). > > I've only tested this on Windows so far. Wouldn't surprise me > if some minor work is needed to build on *nix. > > I'm also unsure if I can get away with the easy way I pass > strings in and out of wx (encoding issues?). It works in my > testcases, but I'm not familiar enough to be sure if it always does. > > Finally, I've added a screenshot for those who don't want to > rebuild :) > > So. Thoughts, and comments? > > //Magnus > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings