Thread: pgadmin3 query tools
Dave Page wrote: >Wow, looks great. Nice work. > >My only thought is that we now have 2 query tools, though with obvious >differences. Any thoughts on the best way to handle that? I think both >are good, but Andreas has obviously spent more time getting the look and >output right, whilst Keith has spent time on the query builder features. > > Sadly, I'm suffering from a complete lack of desire concerning a query builder... ;-) What I need is a fast, abortable tool that can handle a lot of data (that's why I dropped wxGrid) and large queries. I like pgadmin2/3's lower right create command window, that's all support I need. Anyway, I don't think it's a big problem to link a query building tool to my query window. An enhanced version (creates partially implemented) of pgadmin3 can be found at www.pse-consulting.de/pgadmin3/pgadmin3.zip Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 30 March 2003 23:14 > To: pgadmin-hackers@postgresql.org; Dave Page > Subject: pgadmin3 query tools > > > Dave Page wrote: > > >Wow, looks great. Nice work. > > > >My only thought is that we now have 2 query tools, though > with obvious > >differences. Any thoughts on the best way to handle that? I > think both > >are good, but Andreas has obviously spent more time getting the look > >and output right, whilst Keith has spent time on the query builder > >features. > > > > > > Sadly, I'm suffering from a complete lack of desire > concerning a query > builder... ;-) No problem, I just don't want 2 seperate query tools. Keith, what are your thoughts? Regards, Dave.
> > Sadly, I'm suffering from a complete lack of desire > > concerning a query > > builder... ;-) > > No problem, I just don't want 2 seperate query tools. > > Keith, what are your thoughts? Dave, I have a lot so I'm going to number these. 1. I just got time to try this build. There is a new bug where if it can't connect to the server it goes into an infinite loop (ok, ok, ok, ok, etc. -- for instance, if the server is not running). Starting the server does not help, you have to kill the PGA3 process. Then restart PGA3. 2. Andreas, thank you for fleshing out the tree. I believe we can use that as a cache. Your additions look great so far. Can you let us know which tree items are missing? It looks like foreign keys might be missing. Languages, functions, operators. We also seem to be missing some of the system objects (such as pg_toast, pg_catalog). 3. Andreas' query tool is similar to the old one from PGA2 ... type the query and it runs. I think that's useful for now. 4. However, I would like to continue to code my Query Builder if that's okay with the both of you. I've done quite a bit of work on it. It's visual, and has more functionality and usefulness than the MS Query tool. Mine will allow unions and extremely complex queries. What we can do is maybe integrate the two at some later time so that you can type free-hand queries into my query builder and get the result. As you know, I made the SQL text box read only for the moment. 5. Andreas, I am REALLY REALLY really happy that you used a structured style for SQL reconstruction. PGA2 was unreadable because it was all on one line. But you might consider using a fixed font so that the tabs line up. 6. Please let me know when this is in CVS. I imagine it will be hard to reconcile the two builds. Andreas did a lot of work and I imagine he started before the memory leak fix. So those are my thoughts. -Keith
Hi Keith > -----Original Message----- > From: efesar [mailto:efesar@nmia.com] > Sent: 31 March 2003 19:37 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > > > Sadly, I'm suffering from a complete lack of desire concerning a > > > query builder... ;-) > > > > No problem, I just don't want 2 seperate query tools. > > > > Keith, what are your thoughts? > > Dave, > > I have a lot so I'm going to number these. > > 1. I just got time to try this build. There is a new bug > where if it can't connect to the server it goes into an > infinite loop (ok, ok, ok, ok, etc. -- for instance, if the > server is not running). Starting the server does not help, > you have to kill the PGA3 process. Then restart PGA3. Yes, I noticed that as well. > 2. Andreas, thank you for fleshing out the tree. I believe we > can use that as a cache. Your additions look great so far. > Can you let us know which tree items are missing? It looks > like foreign keys might be missing. Languages, functions, > operators. We also seem to be missing some of the system > objects (such as pg_toast, pg_catalog). I've been thinking about that, and the majority of places we use such info, we only need to oid & identifier. I wonder if it would be easier to build some fast, dedicated caches for that instead. We do acctually have some of these internally in pgSchema (pga2), but in this code they could be globally accessible within a pgDatabase. > 3. Andreas' query tool is similar to the old one from PGA2 > ... type the query and it runs. I think that's useful for now. > > 4. However, I would like to continue to code my Query Builder > if that's okay with the both of you. I've done quite a bit of > work on it. It's visual, and has more functionality and > usefulness than the MS Query tool. Mine will allow unions and > extremely complex queries. What we can do is maybe integrate > the two at some later time so that you can type free-hand > queries into my query builder and get the result. As you > know, I made the SQL text box read only for the moment. What I think might be nice, would be to move the QB code onto a tab with Andreas' SQL textbox. Leave his grid/explain output tabs at the bottom, so we have both on one form. Of course, parsing manually entered SQL to populate the QB fields wouldn't really be an option, but at least we could take the best bits from your respective work and build a killer qeury tool. On a related note (can't remember if I mentioned this), I recently argued for the addition of the attrelid & attnum fields to the RowDescription message for the new 7.4 protocol. This will allow us to more easily build delete/update/insert queries based on user supplied SQL without going through the fun of parsing the SQL as pga2 does. > 5. Andreas, I am REALLY REALLY really happy that you used a > structured style for SQL reconstruction. PGA2 was unreadable > because it was all on one line. But you might consider using > a fixed font so that the tabs line up. 'scuse me!! What's wrong with pga2's output? It's multiline - I take great care to format it nicely in fact... Talking of which - Andreas, I noticed that tables are being prefixed with the owner name rather than the schema name. > 6. Please let me know when this is in CVS. I imagine it will > be hard to reconcile the two builds. Andreas did a lot of > work and I imagine he started before the memory leak fix. Done (cvs currently at 193.195.77.163). I believe Andreas did get your memory fixes in, but please check. > So those are my thoughts. Thanks :-) Regards, Dave.
Dave, > 'scuse me!! What's wrong with pga2's output? It's multiline - I take > great care to format it nicely in fact... My bad. I was looking at PGA2 and I realized my mistake. Views are not structured ... Which I realize now is also true of PGA3. Are they stored that way in the database? Is there anyway we can structure them? The reason I ask is because I have some monster views and it's almost impossible to read them if they aren't structured. Sorry about that. -Keith
> > 1. I just got time to try this build. There is a new bug > > where if it can't connect to the server it goes into an > > infinite loop (ok, ok, ok, ok, etc. -- for instance, if the > > server is not running). Starting the server does not help, > > you have to kill the PGA3 process. Then restart PGA3. > > Yes, I noticed that as well. Submitting patch for that. > I've been thinking about that, and the majority of places we use such > info, we only need to oid & identifier. I wonder if it would be easier > to build some fast, dedicated caches for that instead. We do acctually > have some of these internally in pgSchema (pga2), but in this code they > could be globally accessible within a pgDatabase. There are pros/cons. The tree is slower than a dedicated cache, but the dedicated cache would have to be refreshed in the same refreshes as the tree. And it would basically end up being a linked list, so we might end up doing double duty. > Done (cvs currently at 193.195.77.163). I believe Andreas did get your > memory fixes in, but please check. Okay, updated and compiled. No memory leaks as far as I can see. -Keith
Attachment
efesar wrote: >My bad. I was looking at PGA2 and I realized my mistake. Views are not >structured ... Which I realize now is also true of PGA3. Are they stored >that way in the database? Is there anyway we can structure them? The reason >I ask is because I have some monster views and it's almost impossible to >read them if they aren't structured. > >Sorry about that. > >-Keith > > Already on my list. Unfortunately, pgsql wipes out all fancy formatting, so we have to guess what a good structure might look like. Regards, Andreas
Hi Dave and Keith, my sources are as of 2003-03-25 12:40. There are several comments about fixed memory leaks (mostly pgSet instances). All objects are supported now, and schema is prefixed instead of owner (pretty easy, just fix in GetQuotedFullIdentifier). Putting the query builder in a second tab of my query window shouldn't be a problem; I'll provide a page for this. Will change the SQL text boxes font to something fixed soon. AFAICS, CVS version is smooth now. Regards, Andreas Dave Page wrote: >Hi Keith > > > >>-----Original Message----- >>From: efesar [mailto:efesar@nmia.com] >>Sent: 31 March 2003 19:37 >>To: pgadmin-hackers@postgresql.org >>Subject: Re: [pgadmin-hackers] pgadmin3 query tools >> >> >> >> >>>>Sadly, I'm suffering from a complete lack of desire concerning a >>>>query builder... ;-) >>>> >>>> >>>No problem, I just don't want 2 seperate query tools. >>> >>>Keith, what are your thoughts? >>> >>> >>Dave, >> >>I have a lot so I'm going to number these. >> >>1. I just got time to try this build. There is a new bug >>where if it can't connect to the server it goes into an >>infinite loop (ok, ok, ok, ok, etc. -- for instance, if the >>server is not running). Starting the server does not help, >>you have to kill the PGA3 process. Then restart PGA3. >> >> > >Yes, I noticed that as well. > > > >>2. Andreas, thank you for fleshing out the tree. I believe we >>can use that as a cache. Your additions look great so far. >>Can you let us know which tree items are missing? It looks >>like foreign keys might be missing. Languages, functions, >>operators. We also seem to be missing some of the system >>objects (such as pg_toast, pg_catalog). >> >> > >I've been thinking about that, and the majority of places we use such >info, we only need to oid & identifier. I wonder if it would be easier >to build some fast, dedicated caches for that instead. We do acctually >have some of these internally in pgSchema (pga2), but in this code they >could be globally accessible within a pgDatabase. > > > >>3. Andreas' query tool is similar to the old one from PGA2 >>... type the query and it runs. I think that's useful for now. >> >>4. However, I would like to continue to code my Query Builder >>if that's okay with the both of you. I've done quite a bit of >>work on it. It's visual, and has more functionality and >>usefulness than the MS Query tool. Mine will allow unions and >>extremely complex queries. What we can do is maybe integrate >>the two at some later time so that you can type free-hand >>queries into my query builder and get the result. As you >>know, I made the SQL text box read only for the moment. >> >> > >What I think might be nice, would be to move the QB code onto a tab with >Andreas' SQL textbox. Leave his grid/explain output tabs at the bottom, >so we have both on one form. Of course, parsing manually entered SQL to >populate the QB fields wouldn't really be an option, but at least we >could take the best bits from your respective work and build a killer >qeury tool. > >On a related note (can't remember if I mentioned this), I recently >argued for the addition of the attrelid & attnum fields to the >RowDescription message for the new 7.4 protocol. This will allow us to >more easily build delete/update/insert queries based on user supplied >SQL without going through the fun of parsing the SQL as pga2 does. > > > >>5. Andreas, I am REALLY REALLY really happy that you used a >>structured style for SQL reconstruction. PGA2 was unreadable >>because it was all on one line. But you might consider using >>a fixed font so that the tabs line up. >> >> > >'scuse me!! What's wrong with pga2's output? It's multiline - I take >great care to format it nicely in fact... > >Talking of which - Andreas, I noticed that tables are being prefixed >with the owner name rather than the schema name. > > > >>6. Please let me know when this is in CVS. I imagine it will >>be hard to reconcile the two builds. Andreas did a lot of >>work and I imagine he started before the memory leak fix. >> >> > >Done (cvs currently at 193.195.77.163). I believe Andreas did get your >memory fixes in, but please check. > > > >>So those are my thoughts. >> >> > >Thanks :-) > >Regards, Dave. > > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to majordomo@postgresql.org so that your >message can get through to the mailing list cleanly > > >
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 31 March 2003 23:57 > To: Dave Page; pgadmin-hackers@postgresql.org; efesar@nmia.com > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > Hi Dave and Keith, > > my sources are as of 2003-03-25 12:40. There are several > comments about > fixed memory leaks (mostly pgSet instances). > > All objects are supported now, and schema is prefixed instead > of owner > (pretty easy, just fix in GetQuotedFullIdentifier). > > Putting the query builder in a second tab of my query window > shouldn't > be a problem; I'll provide a page for this. > > Will change the SQL text boxes font to something fixed soon. > > AFAICS, CVS version is smooth now. Thanks Andreas. I'll need to find some time to get on with the Property dialogues, though thanks to your hard work that should be a fair bit easier now. Keith, are you happy to look at moving the QB onto Andreas' query form, or does that create problems/worries? Regards, Dave.
> -----Original Message----- > From: efesar [mailto:efesar@nmia.com] > Sent: 01 April 2003 00:05 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: RE: [pgadmin-hackers] pgadmin3 query tools > > > > > > 1. I just got time to try this build. There is a new bug > where if it > > > can't connect to the server it goes into an infinite loop > (ok, ok, > > > ok, ok, etc. -- for instance, if the server is not running). > > > Starting the server does not help, you have to kill the PGA3 > > > process. Then restart PGA3. > > > > Yes, I noticed that as well. > > Submitting patch for that. Thanks, committed. > > I've been thinking about that, and the majority of places > we use such > > info, we only need to oid & identifier. I wonder if it > would be easier > > to build some fast, dedicated caches for that instead. We > do acctually > > have some of these internally in pgSchema (pga2), but in this code > > they could be globally accessible within a pgDatabase. > > There are pros/cons. The tree is slower than a dedicated > cache, but the dedicated cache would have to be refreshed in > the same refreshes as the tree. And it would basically end up > being a linked list, so we might end up doing double duty. Yeah, but at least we needn't rely on the user to have accessed that part of the tree to get the cache. I reckon it will be quicker - even if only in the users' perception. I'm not sure we even need to go as far as a linked list do we? Won't a 2 dimensional array do it? We will know the size when it's create after all. Anyway, even if we do it's not particularly difficult - I would be tempted to knock up generic cache/cache object classes. Regards, Dave.
> -----Original Message----- > From: efesar [mailto:efesar@nmia.com] > Sent: 31 March 2003 23:39 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > Dave, > > > 'scuse me!! What's wrong with pga2's output? It's multiline > - I take > > great care to format it nicely in fact... > > My bad. I was looking at PGA2 and I realized my mistake. > Views are not structured ... Which I realize now is also true > of PGA3. Are they stored that way in the database? Is there > anyway we can structure them? The reason I ask is because I > have some monster views and it's almost impossible to read > them if they aren't structured. > > Sorry about that. Don't worry 'bout it :-) Regards, Dave.
> Keith, are you happy to look at moving the QB onto Andreas' query form, > or does that create problems/worries? Dave, The Query Builder is based on an MDI Parent/Child structure. The parent is a frame, so I don't think it can be bound to any other windows. So that might be a problem. We might consider going the opposite way, and I can add the icons and functionality of the query tool to the Query Builder. Don't know for sure, let me know if you have ideas there. -Keith
efesar wrote: >Dave, > >The Query Builder is based on an MDI Parent/Child structure. The parent is a >frame, so I don't think it can be bound to any other windows. So that might >be a problem. We might consider going the opposite way, and I can add the >icons and functionality of the query tool to the Query Builder. Don't know >for sure, let me know if you have ideas there. > >-Keith > Hi Keith, Uh, I hate MDI. You're using it at the moment to keep tables and views, and MDI looks quite reasonable for this (actually, the first time MDI looks good for me). I don't see how the sql input field should be assembled into the existing query builder, unless the second notebook page is used; I really wouldn't like that. Actually, I INSIST that the query window as it is now (on top query, below result) is somehow retained. Explicitely I don't like the edit window to become a MDI child. I'll sound quite harsh about this, but this part of pgadmin2 was the trigger for me to jump into pgadmin3, and if that feature is spoiled or degraded I'll be really upset. Nevertheless, there are other ways. I can think of an additional window (some kind of assistant, as MS would call it), that can be opened, and which will inject the query into the query execution window (directly executing or pasted into the editor). Another way would be to extract the lower part (notebook, listview and messages) into an isolated control, making it reusable Then we would have two query tools, targeted to quite different users. To hide this fact, the used sql tool could be selected from "options" (standard/advanced). (btw keith: checking for relowner > 1 in dlgAddTableView will hide all my tables... check for system namespace instead) Regards,
> Uh, I hate MDI. You're using it at the moment to keep tables and views, > and MDI looks quite reasonable for this (actually, the first time MDI > looks good for me). I don't see how the sql input field should be > assembled into the existing query builder, unless the second notebook > page is used; I really wouldn't like that. Actually, I INSIST that the > query window as it is now (on top query, below result) is somehow > retained. Explicitely I don't like the edit window to become a MDI > child. I'll sound quite harsh about this, but this part of pgadmin2 was > the trigger for me to jump into pgadmin3, and if that feature is spoiled > or degraded I'll be really upset. The only thing that is MDI is the table/view windows, and that should remain true. I dislike MDI as well, and I wanted to avoid it. However, it was the easiest way to do what was necessary. To build clipped frames in a similar manner seems like unnecessary effort. The reason I would like to build my own Pseudo-MDI class (in the future) is to avoid the uncustomizable MDI framework in wxWindows. Here are my two cents. We put a "view" menu in BOTH our tools. It will either have a checkmark on Query Builder or on Query Analyzer (or the preferred name, of course). When in the Query Builder, if they check on Query Analyzer, it will close itself and open your tool. Vice versa in your tool. And we can share window placement. We can even work on merging them into one class, since wxMDIParentFrame is derived from wxFrame. That's just a consideration. I'd like your feedback and Dave's as well. BTW, this paragraph refers to "some later date" after I have a nearly functional Query Builder. It would be too easy for conflicts to develop if we merge them now. For now I'm simply going to duplicate your menus and methods and icons. > Nevertheless, there are other ways. I can think of an additional window > (some kind of assistant, as MS would call it), that can be opened, and > which will inject the query into the query execution window (directly > executing or pasted into the editor). > Another way would be to extract the lower part (notebook, listview and > messages) into an isolated control, making it reusable Then we would > have two query tools, targeted to quite different users. To hide this > fact, the used sql tool could be selected from "options" > (standard/advanced). I believe Dave wants to avoid two tools. See merge idea from previous paragraph with the "view" menu option. I have no problem with putting the QB tabs at the bottom. The only reason I put them at the top is simple negligence. In fact, I'm changing that as we speak and will be in my next CVS update. > (btw keith: checking for relowner > 1 in dlgAddTableView will hide all > my tables... check for system namespace instead) That's old code. It's been namespaced for more than a month. In any case, we're still working on the object caching solution, so direct DB queries are a temporary workaround. BTW, I finally did come across some memory leaks in the additional tree code. I haven't pinpointed them yet, but it looks like some database object is not being deleted after it's allocated. I'll try to do more testing to get further data on the memory leaks to you. -Keith
Hi Keith, efesar wrote: >The only thing that is MDI is the table/view windows, and that should remain >true. I dislike MDI as well, and I wanted to avoid it. However, it was the >easiest way to do what was necessary. To build clipped frames in a similar >manner seems like unnecessary effort. The reason I would like to build my >own Pseudo-MDI class (in the future) is to avoid the uncustomizable MDI >framework in wxWindows. > >Here are my two cents. We put a "view" menu in BOTH our tools. It will >either have a checkmark on Query Builder or on Query Analyzer (or the >preferred name, of course). When in the Query Builder, if they check on >Query Analyzer, it will close itself and open your tool. Vice versa in your >tool. And we can share window placement. > That's not far from my solution, switching from one to the other with a menu/toolbar. We would have two tools, I wouldn't really bother about that. As I wrote, the core code could be wrapped into a control, either derived from wxNotebook or wxListView, whatever is more useful. There might be another argument towards two distinct tools: Porting to **ix might be easier. Don't know when I find the time to check with Linux (maybe weekend), I strongly doubt that my threading code will work there too. > >We can even work on merging them into one class, since wxMDIParentFrame is >derived from wxFrame. That's just a consideration. I'd like your feedback >and Dave's as well. > Hmbpf. I don't believe that works. wxMDIParentFrame bends that poor wxFrame in a manner that I doubt it will still behave like a normal wxFrame for me. >BTW, this paragraph refers to "some later date" after I >have a nearly functional Query Builder. It would be too easy for conflicts >to develop if we merge them now. For now I'm simply going to duplicate your >menus and methods and icons. > Agreed, there are still wishes about the file menu I want to implement. > > > >I believe Dave wants to avoid two tools. See merge idea from previous >paragraph with the "view" menu option. > >I have no problem with putting the QB tabs at the bottom. The only reason I >put them at the top is simple negligence. In fact, I'm changing that as we >speak and will be in my next CVS update. > > That's not a special concern to me. For the query builder, it even might be a better solution. On the other side, it will look more consistent if it's always at the bottom. >That's old code. It's been namespaced for more than a month. > Not flushed to cvs? >In any case, >we're still working on the object caching solution, so direct DB queries are >a temporary workaround. > > Look at pgTable::GetSql(), there I browse, force pgCollections to populate and update pgColumns. It's easy, and could be done from PG_TABLES as well. Calling ShowTreeDetails(browser,0,0,0,0) has virtually no cost after the first call. >BTW, I finally did come across some memory leaks in the additional tree >code. I haven't pinpointed them yet, but it looks like some database object >is not being deleted after it's allocated. > That's totally impossible. A long time ago, I decided to write error free code. Since then, my code has been proven to be complete, precise, delicious, juicy, absolutely genious and defect free. Well, almost... ;-) >I'll try to do more testing to get further data on the memory leaks to you. > Just tell me where you find something. And I'll find out who's at my machine adding that leaks while I'm off-site. Just reviewed all ExecuteSet and found two missing pgSet deletes in pgColumn and pgSequence. Best regards, Andreas
Hi guys, > -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 02 April 2003 01:50 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > >Here are my two cents. We put a "view" menu in BOTH our > tools. > That's not far from my solution, switching from one to the > other with a > menu/toolbar. We would have two tools, I wouldn't really bother about > that. As I wrote, the core code could be wrapped into a > control, either > derived from wxNotebook or wxListView, whatever is more > useful. That's fine with me. My major concern is that the code that drives the grid is only written once. This is likely to get quite complex once editting features are added, and I don't want to maintain 2 copies. I always want to keep the look and feel consistant. So, how about we create a class derived from the wxNotebook as Andreas suggests, which can just be passed the completed query to display the results and allow editting thereof (where possible), and display explain output (and hopefully one day we can add a visual explain tab). There might be another argument towards two distinct > tools: Porting to > **ix might be easier. The biggest problem we're finding in *nix is that the ctor for wxString doesn't like taking an initial value (iirc). Mark, I know you're busy, but if you get 5 minutes, can you do an update and try rebuilding on Linux please? It's possible that there are one or two source files missing from the Makefile... > Just tell me where you find something. And I'll find out who's at my > machine adding that leaks while I'm off-site. Just reviewed all > ExecuteSet and found two missing pgSet deletes in pgColumn > and pgSequence. Ahh, those pesky code pixies.... Regards, Dave.
Dave Page wrote: > >That's fine with me. My major concern is that the code that drives the >grid is only written once. This is likely to get quite complex once >editting features are added, and I don't want to maintain 2 copies. I >always want to keep the look and feel consistant. > >So, how about we create a class derived from the wxNotebook as Andreas >suggests, which can just be passed the completed query to display the >results and allow editting thereof (where possible), and display explain >output (and hopefully one day we can add a visual explain tab). > > > Hi, I don't think it's a good idea trying to inject editing features in the current wxListView. Actually, my first implementation used wxGrid, but was a real pain for bigger result sets. SELECT * from pg_attribute (200 rows) wouldn't complete within 30 seconds, and the destruction of a 2000 row grid (without data) would consume several seconds! From that times, we got that split elapsed seconds display to see how the time splits between query execution and result retrieval. Actually, I see YAQT (yet another query tool) for editing a table. You just pick a table (maybe view), hit "Edit" and scroll up and down in there. It must be capable of unlimited rows, which isn't easy but can be done (I already implemented something like that in earlier days). And it should have inline editing, feels better than the current pgadmin2 solution. We got different recommendations, so we need different tools. If we try to put all into one, we get only second best. And you will agree, pgsql is worth only the best. Regards, Andreas
It's rumoured that Andreas Pflug once said: > Actually, I see YAQT (yet another query tool) for editing a table. You > just pick a table (maybe view), hit "Edit" and scroll up and down in > there. It must be capable of unlimited rows, which isn't easy but can > be done (I already implemented something like that in earlier days). > And it should have inline editing, feels better than the current > pgadmin2 solution. So you're saying we make the arbitrary query tools (SQL/QB) produce very fast, but read-only output, but add an 'Edit' option for tables/views, that allows editting of their contents an a purpose designed grid? That would certainly be easier to code as we would always know the base structure of what we were editting... > We got different recommendations, so we need different tools. If we try > to put all into one, we get only second best. And you will agree, > pgsql is worth only the best. Absolutely. Regards, Dave.
Dave Page wrote: >So you're saying we make the arbitrary query tools (SQL/QB) produce very >fast, but read-only output, but add an 'Edit' option for tables/views, >that allows editting of their contents an a purpose designed grid? >That would certainly be easier to code as we would always know the base >structure of what we were editting... > Exactly. I've seen quite a lot of querying tools, and most of them were quite ugly and at the edge of usability. For my experience, I think two tool windows are the easiest way to handle it, not only in concerning coding, but also regarding user handling. The best tool I've been working with was MSSQL2000's ISQLW, which does use separate windows for editing and arbitrary query output. And pgadmin3 is going to be better, because its schema representation is better. > > >>We got different recommendations, so we need different tools. If we try >> to put all into one, we get only second best. And you will agree, >>pgsql is worth only the best. >> >> > >Absolutely. > For a programmer, acceptance stands and falls by the tools. We are on the way to supply a tool that leaves virtually no wishes. Let's show those big companies that open software is better! Who needs O.., who needs M..., we got PostgreSQL! Regards, Andreas
It's rumoured that Andreas Pflug once said: > Exactly. I've seen quite a lot of querying tools, and most of them were > quite ugly and at the edge of usability. For my experience, I think > two tool windows are the easiest way to handle it, not only in > concerning coding, but also regarding user handling. The best tool > I've been working with was MSSQL2000's ISQLW, which does use separate > windows for editing and arbitrary query output. And pgadmin3 is going > to be better, because its schema representation is better. Yup, certainly is. BTW, did you know that thanks to Frank Lupo, pga2 fully supports Casts and Conversions in the schema now? > For a programmer, acceptance stands and falls by the tools. We are on > the way to supply a tool that leaves virtually no wishes. Let's show > those big companies that open software is better! Who needs O.., who > needs M..., we got PostgreSQL! Damn straight!! :-) Regards, Dave.
Dave Page wrote: >Yup, certainly is. BTW, did you know that thanks to Frank Lupo, pga2 fully >supports Casts and Conversions in the schema now? > > OK, message understood. CAST, CONVERSION and OPERATOR CLASS are missing in pgadmin3 (yet). Any more objects of your desire? Centerfolds excepted. Regards, Andreas
Andreas, > >That's old code. It's been namespaced for more than a month. > > I just committed the changes that deal with that. Go ahead and update. Also there is a bit more functionality on the QueryBuilder. I'll be spending most of the day finishing up what I started. It should be mostly done by the end of today (unless the coffee wears off). > Look at pgTable::GetSql(), there I browse, force pgCollections to > populate and update pgColumns. It's easy, and could be done from > PG_TABLES as well. > Calling ShowTreeDetails(browser,0,0,0,0) has virtually no cost after the > first call. Good to know. > That's totally impossible. A long time ago, I decided to write error > free code. Since then, my code has been proven to be complete, precise, > delicious, juicy, absolutely genious and defect free. > Well, almost... ;-) :) It must have a been some M*cr*s*ft conspirator. > Just tell me where you find something. And I'll find out who's at my > machine adding that leaks while I'm off-site. Just reviewed all > ExecuteSet and found two missing pgSet deletes in pgColumn and > pgSequence. I can't find them now, so I'm guessing the missing deletes cleared them up. -Keith
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 02 April 2003 14:20 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > Dave Page wrote: > > >Yup, certainly is. BTW, did you know that thanks to Frank Lupo, pga2 > >fully supports Casts and Conversions in the schema now? > > > > > OK, message understood. > CAST, CONVERSION and OPERATOR CLASS are missing in pgadmin3 > (yet). Any > more objects of your desire? :-) Wow, you're good - done already I see... A couple of minor issues I found: - Casts do not live in a schema. They need to live alongside languages with the database as parent. - I don't see the pg_catalog schema no matter whether I have system objects on or off. I always see pg_temp_*. - Keith's fix for the login loop doesn't work. If you get your password wrong, it never let's you renenter it. What used to happen was it called the login code again (the bit Keith commented out), but let you re-enter the password and other details if appropriate. On a more general note, one og the most useful things in pga2 is the logging system. There is one in pga3 tied in with wxLog - can we start using it liberally please 'cos it's invaluable for support purposes. sysLogger::DoLog() shows what each level will do. > Centerfolds excepted. D'oh! Thanks for your effort guys. Regards, Dave.
Dave Page wrote: >A couple of minor issues I found: > >- Casts do not live in a schema. They need to live alongside languages >with the database as parent. > Done. >- I don't see the pg_catalog schema no matter whether I have system >objects on or off. I always see pg_temp_*. > Done. Ordered System/Temp/standard namespaces. Please have a look at the properties and sql output of all objects. This should be checked by somebody different from the code hacker, who's normally blind... Maybe this task could be performed by somebody else? Expecially weird cases with mixed namespaces for functions within one object could be unhandled (missing schema) or "overhandled", i.e. shown fully qualified while only legal within same namespace.Last pgAdmin3 version always available at http://www.pse-consulting.de/pgadmin3/pgadmin3.zip >- Keith's fix for the login loop doesn't work. If you get your password >wrong, it never let's you renenter it. What used to happen was it called >the login code again (the bit Keith commented out), but let you re-enter >the password and other details if appropriate. > Done. Still, in OnCancel() cursor won't switch back to pointer; could be nasty to find so it's postponed.Actually, without having gone into it, seems to be a wxWindows fault. > >On a more general note, one og the most useful things in pga2 is the >logging system. There is one in pga3 tied in with wxLog - can we start >using it liberally please 'cos it's invaluable for support purposes. >sysLogger::DoLog() shows what each level will do. > > This needs some modification; sql is shown only for "debug" level. Do you like all those "pgXxx created"? pgadmin2's level seem to be what we need. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 03 April 2003 14:50 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > Dave Page wrote: > > >A couple of minor issues I found: > > > >- Casts do not live in a schema. They need to live alongside > languages > >with the database as parent. > > > Done. Thanks. > > >- I don't see the pg_catalog schema no matter whether I have system > >objects on or off. I always see pg_temp_*. > > > Done. Ordered System/Temp/standard namespaces. Thanks. > Please have a look at the properties and sql output of all > objects. This > should be checked by somebody different from the code hacker, who's > normally blind... Maybe this task could be performed by > somebody else? Expecially weird cases with mixed namespaces > for functions within one > object could be unhandled (missing schema) or "overhandled", > i.e. shown > fully qualified while only legal within same namespace.Last pgAdmin3 > version always available at > http://www.pse-consulting.de/pgadmin3/pgadmin3.zip I (or Mark) should be able to handle this, but if there are other volunteers, please feel free. > >- Keith's fix for the login loop doesn't work. If you get > your password > >wrong, it never let's you renenter it. What used to happen was it > >called the login code again (the bit Keith commented out), > but let you > >re-enter the password and other details if appropriate. > > > Done. Still, in OnCancel() cursor won't switch back to > pointer; could be > nasty to find so it's postponed.Actually, without having gone > into it, > seems to be a wxWindows fault. Thanks. Odd... > > > >On a more general note, one og the most useful things in pga2 is the > >logging system. There is one in pga3 tied in with wxLog - > can we start > >using it liberally please 'cos it's invaluable for support purposes. > >sysLogger::DoLog() shows what each level will do. > > > > > This needs some modification; sql is shown only for "debug" level. Do > you like all those "pgXxx created"? > pgadmin2's level seem to be what we need. The difficulty there was mapping the pgAdmin debug levels into wxWindows. As 99% of the time I use Errors/SQL/Full Debug, I decided to include only those plus None. As for all the pgXxx created's, we probably don't need those as long as we do put in meaningful messages elsewhere. In pga2, we log every function entry on Full Debug which is handy if we need to figure out the call stack, but otherwise can be a pain. What do you think? I vaguely remember reading somewhere that glibc has some sort of call stack macro that you can use at runtime anyway... Can Windows do anything like that in a non-debug build? Regards, Dave.
> -----Original Message----- > From: Dave Page > Sent: 03 April 2003 15:02 > To: Andreas Pflug; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3 query tools > > > >- Keith's fix for the login loop doesn't work. If you get > > your password > > >wrong, it never let's you renenter it. What used to happen was it > > >called the login code again (the bit Keith commented out), > > but let you > > >re-enter the password and other details if appropriate. > > > > > Done. Still, in OnCancel() cursor won't switch back to > > pointer; could be > > nasty to find so it's postponed.Actually, without having gone > > into it, > > seems to be a wxWindows fault. > > Thanks. Odd... Actually this bug still seems to exist. I think I've fixed it now, but the hourglass remains as you observed. I have to wonder if there is a better way of handling the initial connection - it does seem a little convoluted. Regards, Dave.
Dave Page wrote: >The difficulty there was mapping the pgAdmin debug levels into >wxWindows. As 99% of the time I use Errors/SQL/Full Debug, I decided to >include only those plus None. As for all the pgXxx created's, we >probably don't need those as long as we do put in meaningful messages >elsewhere. In pga2, we log every function entry on Full Debug which is >handy if we need to figure out the call stack, but otherwise can be a >pain. > It seems to me as if the debug levels could be extended. I'll have a look at it. > >What do you think? I vaguely remember reading somewhere that glibc has >some sort of call stack macro that you can use at runtime anyway... Can >Windows do anything like that in a non-debug build? > > > Dr. Watson does it. If you got a matching debug library for a nondebug build, you can diagnose a crashdump afterwards. Anyway, a full debug log should do also. Regards, Andreas