[pgadmin-hackers] Admin4 - anybody interested?
Hi Folks, long time no hear! And well, this is a one-time only contact, I'm not going to re-join the pgAdmin community (not even subscribed to the list). The intention of my mail is to bring Admin4 ( http://www.admin4.org ) to your attention, maybe show new perspectives and eventually attract fellow developers. Back in those old days, I thought pgAdmin sources might be the base for more administrative tools, but that's actually not too easy since the extension mechanisms weren't included by design but added later. I dreamt of including a Python scripting engine, which never happened either. So over the past years, when I was in urgent need for a management tool for specific type of (non-public) server, I created a tool from scratch that is meant to offer maximum flexibility and extensibility, Admin4. It is extensible on different levels: modules (different types of servers), nodes (different objects in servers), panels/menus/tools (added features to nodes), and more; all without configuration or modification of existing files, just by adding some files. Of course, it's multi-platform (Python/wxPython) and open source (Apache2). It gained some more modules: aside from the first undisclosed module, it offers LDAP and BIND/DNS modules, and lately a PostgreSQL module. In contrast to LDAP and DNS modules, the PostgreSQL module hasn't reached the feature-complete status; I'm coding just what I currently need, but what's mostly missing is support of some more node types and editing of them; the boring stuff ;-) IMHO very usable is the query tool and the data tool, both having some helpful non-trivial features other tools don't have. The Admin4 core itself is quite stable, infrastructure (website, sourceforge, github) including secure online update is settling. I assume the most people interested in stuff like Admin4 would be lurking around here, so if you'd like to have a peek, check it out! Regards, Andreas -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] pgAdmin licence
Dave Page wrote: My offer to get and review my changes in order to extract them for the official pgAdmin never got an answer. I honestly never received such an email, and would have been glad to accept had I done. As for leaving the team, you unsubscribed from all the mailing lists and said something to the effect of 'I'm never going to work on pgAdmin again' which I took as a resignation from the team. I investigated this point, and indeed you answered that mail (last year on Sep 19th). You didn't react to my code offer in that mail though. If I misunderstood what you were saying, then I sincerely apologise and would be keen to put things right if you are willing. Hm, I wonder what you mean by put things right. Rereading those few mails from Sep'06, I found that all issues still apply. Actually, pgadmin design has shifted in a way I never would have accepted for good reasons (I called it gui and usability foolishness back then; it applies to 1.8 even stronger). I'm sure you do NOT know what I mean but there's certainly no point complaining about a tool I don't use. So if you want to put things right in order to have me entering the pgadmin project again, no chance. I'd stir up things in a way many people would dislike (apart from the fact that, in contrast to the situation when pgAdmin III was started, I DO have an admin tool that works for me, with everything I need so there's little motivation for me). When it's about anything non-pgadmin related, I only can repeat the last sentence of that old mail: I'd still drink a beer with you, though. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pgAdmin licence
Dave Page wrote: Andreas Pflug wrote: Dave whatsup? I'm trying to do three things (in no particular order): 1) Change the pgAdmin licence to Artistic 2.0 and above. You are the only developer who has refused permission to do that, however that is your right and we will respect it. 2) Protect the rights of those who have contributed to pgAdmin. You have stated that your private work for your customers was broken by changes to pgAdmin, and that you have used pgAdmin base classes in pgImport which is not distributed in any way that would satisfy the pgAdmin licence. You have since said that you're not using any pgAdmin code. 3) Understand why we've been having this pointless argument for 18 months now. Originally I thought it was because you disagreed with the decision that was made to use the wxGrid control in the Query Tool but earlier in this thread you said that was not the case. You then said it was because I changes the Windows build environment to VC8 without consulting you, however the archives show that we did discuss it and the only concern you raised turned out to be a non-issue. Point 1 is resolved. Point 2 is still an unknown. Are you using pgAdmin or pgAdmin-derived code in any projects without fulfilling the requirements of the licence? If you are, I would ask that you rectify that as soon as practical. OMG. Can you imagine I feel I can't use my own code as I wish? For peace sake, I added a reference to the version info. Point 3 leaves me both saddened and confused. Given your recent comments, and the history in the list archives I cannot understand why this disagreement is happening or how it started. We've worked together on pgAdmin for years, and we've drunk beer together on the other side of the world. Can we not resolve this and move on? Depends on what you call resolve and move on. I'm not inclined to reread and quote the messages we exchanged back then (most of them in private IIRC), so in short from my memory: - you removed working code, replacing it with half-brewn wxGrid code that had some bad behaviour. I used the query tool heavily, and rely on it, and thus was annoyed seeing the main tool (at least temporarily) degraded. To repeat, I'm exceptionally sensitive about the query tool because it was the main reason to start work on pgAdmin. I know I made this point very clear. I recommitted the working stuff, leaving wxGrid code there for conditional compilation, you removed it completely again. Over the next weeks, I used my non-committed trunk (to stay working), and enhanced it quite a bit (I can recall it only partially, because I don't have any logs from that time since I started my own svn a while later. It covered e.g. Slony support that was broken as I found when using it). At the same time, you removed VC6 support, which I didn't realize immediately because I didn't contact svn for a while. When finally you understood the conditional compilation way I wanted to introduce, giving us back some common understanding, I tried to start to updating/committing and found my dev env f***ed up, with svn and my version severely diverged. Bummer. At that time I was heavily p***ed and decided that I could maintain my pgAdmin fork to my personal needs, and observing how fast I was removed from the pgAdmin team you seemed to like that. My offer to get and review my changes in order to extract them for the official pgAdmin never got an answer. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pgAdmin licence
Dave Page wrote: --- Original Message --- From: Andreas Pflug [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 12/10/07, 22:11:36 Subject: Re: pgAdmin licence Dave, since pgImport was originally written to import from file to MSSQL, with pgsql support added later (and pgConnection/pgSet never supported COPY), you're trying to see stuff that's not there (nor is factory.cpp). So when you said: The base classes however are reused by several other projects, including pgImport. were you making it up? If you are not using pgAdmin code in your closed source projects, why was it such a problem when the pgAdmin project files were upgraded which, as you said, broke your other private code? Dave whatsup? Are you trying to take the words out of my mouth? pgImport is a few weeks old and just a tool for me (and whoever likes to use it), not customer software projects as the one that were broken back then. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pgAdmin licence
Dave Page wrote: Andreas Pflug wrote: No. You removed VC6 support, which was absolutely vital for me, without ever asking whether that was viable. Since my development was tightly integrated, I wasn't able to switch one of projects separately (at least in the timeframe available). Oh, I'm sorry - I thought it was the wxGrid thing you objected to. WRT to moving to VC++ 2005, I *did* ask your opinion (and even stated 'and drop VC++6 support'), and the only objection you raised was that you thought we'd have to link with the .NET runtimes which I investigated and found was not the case. The thread is here: http://archives.postgresql.org/pgadmin-hackers/2006-04/msg00054.php Regardless, if you needed to retain VC++ 6.0 support for compatibility with your private work, surely it would have been infinitely easier to just maintain your own project file, rather than forking and having to duplicate all the effort to keep up to date with new PostgreSQL releases? Yes, but not the query tool nor any of its helper classes. The base classes however are reused by several other projects, including pgImport. As far as I can see, that puts you in breach of our licence as the distribution you posted a link to on your PSE Consulting website (www.pse-consulting.de/pg/pgImport.zip) includes *only* a zipped executable and no sign of any of the requirements of the pgAdmin licence. Much of the base class code in pgAdmin was written or modified by me (particularly the connection and recordset classes) and therefore cannot be claimed as your own original work. I don't think so. It was me who invented the db base classes, besides they have undergone some major rewrite (ever heard of pgSetIterator?) I checked quite thoroughly, including the icon (which I'd replace if I had another one at hand). 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] pgAdmin licence
Dave Page wrote: This email has been sent to you because our records indicate that at some point in the past you have contributed to the pgAdmin III project (http://www.pgadmin.org). It this is not the case, please let me know as soon as possible. Since it was first released, pgAdmin III has been distributed under version 1.0 of the Artistic licence. I am writing to request your permission to distribute the code you have submitted under version 2.0 of the Artistic licence, and any future versions that might be published. There are a number of reasons why we would like to change the licence used by pgAdmin (per Tom Callaway of Redhat): - The FSF says it isn't free. They say that the text is vague, and that it is open to misinterpretation. - The perl community agrees with this assessment. They went so far as to rewrite the Artistic license to resolve all the identified problems (see http://www.perlfoundation.org/artistic_license_2_0). - The Artistic License (1.0) recently went to trial in the US and lost. The judge interpreted it in a very negative way, and that worries me. (http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source-legal-decision-jacobsen.html) I'm sure you will agree that it would be sensible for us to use the newer version of the licence in the future and would therefore appreciate it if you could reply to this email as soon as possible stating either: * I agree for all contributions I have made to the pgAdmin III project to be distributed under version 2.0 or any future versions of the Artistic licence. or: * I do not agree to any licence change for contributions I have made to the pgAdmin III project. Dave, for me the worst case already happened last year, when I had to fork my own code to continue my job. As a consequence, I won't give away control over sources any more for tools I release to the public, such as www.pse-consulting.de/pg/pgImport.zip. I do NOT agree to change licensing on my prior code. Regards, Andreas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgadmin-hackers] pgAdmin licence
Dave Page wrote: Andreas Pflug wrote: for me the worst case already happened last year, when I had to fork my own code to continue my job. As a consequence, I won't give away control over sources any more for tools I release to the public, such as www.pse-consulting.de/pg/pgImport.zip. I find that an incredible claim. You stopped working on pgAdmin because a majority of the developers at the time thought there were tangible benefits from the use of wxGrid in the Query Tool over wxListCtrl. No. You removed VC6 support, which was absolutely vital for me, without ever asking whether that was viable. Since my development was tightly integrated, I wasn't able to switch one of projects separately (at least in the timeframe available). You couldn't produce a single provable technical reason why that was the case, except to say you didn't think it would work properly. Since then we haven't had a single bug reported that could be attributed to the use of wxGrid. In the UK we refer to that as throwing the toys out of the pram. I assume from what you say about your job however was that the real reason you didn't want those changes made was because you relied on the existing code for some extensions you had written for your own private use Yes, but not the query tool nor any of its helper classes. The base classes however are reused by several other projects, including pgImport. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - in trunk/pgadmin3:
Dave Page wrote: - I reviewed the patch and found it to be of good quality, restoring the broken functionality, without breaking your speed improvements. I applied the patch. To me, *your* patch broke the source. You removed the code I insisted to retain until the other stuff is completely accepted a second time; simple #ifdef would have been enough. I made very clear that messing around with the query tool is unacceptable to me since it was and is *the* essence of pgadmin to me. You want me out, I am out. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] CHANGELOG
Dave Page wrote: Hi, I added the version number back into all the changelog entires that you removed them from. We know what the version number will be so it makes no sense not to include it now and save me 10 minutes of post-release editting later on. Um, until 1.4 we didn't fill the version number until we really had a release. Since features may move in and out, some might be marked as relased that never will. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] SVN Commit by dpage: r5106 - in trunk/pgadmin3:
[EMAIL PROTECTED] wrote: Author: dpage Date: 2006-04-30 21:13:00 +0100 (Sun, 30 Apr 2006) New Revision: 5106 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5106view=rev Log: Pre-encrypt passwords before sending them down the wire or displaying them in SQL statements. Is that a good idea to do this in a private md5 implementation? libpq is going to/already exporting a method for this, which will make us less sensitive to backend changes. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Reporting
Dave Page wrote: Right, let me give you a quick rundown on whats /currently/ there as this may affect how things can potentially work with the factories. - pgObject and each derived class return a report menu for the current object using GetReportMenu (in pgObject) and GetObjectReportMenu (in the derived class) - Standard reports (ie. Properties, stats, dependencies) are implemented in pgObject. To avoid code duplication and ease the chore of adding new properties, rather than reimplement functions like ShowStatistics/ShowDepends in report format, we simply pass a pointer to the listview control on frmMain to frmReport::AddReportTableFromListView(), which creates a table in the rpeort mimicing the list view. - Object list reports are only apppropriate in pgCollections of course, and thus are implemented at that level. - Object specific reports (currently there are none, but a Table Data Dictionary is first on my list) would be implemented in the appropriate object class. ok Now, for the future... Reimplementing the menus making full use of the factories should not be a problem. You mentioned implementing reports in frmReport. That seems wrong as it means that it will need intimate knowledge of each object type. It seems to me that this info should be encapsulated within the object or one of it's base classes such that frmReport remains generic, and object-specific code is self contained. Well, so far there's no object specific stuff. I'd prefer object extensions that are not rendering/output format specific, and thus don't call back frmReport methods but merely deliver the data for frmReport to render. That said, the generic reports that are there now could go in frmReport as they only need knowledge of frmMain (which I see is passed to StartDialog anyway). This would also work for the list reports that are currently in pgCollection as that can be tested through IsCollection(). Sound reasonable? Anything important I obviously haven't thought about? Sounds ok. In related news, the scripts look handy, but don't seem to work if there is only one script option on the menu, Hu, thanks. Will fix. and the report options are being repeated now, though that doesn't really matter of course. I already removed some of that new object style handling stuff, probably failed to put it in back when backing out my menu change attempt. I still do have a little problem of the overall feature. I do understand the need for reports, but the current approach seems quite limited to me. In general, I'd expect that reports on single objects are not too helpful; a quick glance at a property window should be enough in most cases. I'd expect something like list details on all functions in schema A and all sequences and tables in schema B as typical requirement for a report on an application's db schema definition, probably embedded in some explaining text, and with a table of contents, printed as PDF. This is quite hardly done from report snippets that are rendered full HTML. It could work like this: - generate XML report snippets on everything needed in a directory, or appended to a common file. - When all snippets are collected, render it to whatever is desired with XSL. I don't object having a made HTML option as it is now, but this would mean a second output option, and we certainly won't like to have all objects with specific reporting facilities recoded each time a new output format is introduced; a good reason to deliver data only from objects, not made lines of report. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] SVN Commit by dpage: r5106 - in trunk/pgadmin3:
Dave Page wrote: I considered this carefully and chose that method for a few reasons. 'k, after having a look what you did a I found you copied the backend's version. I agree with your arguments. AFAICS this is basically a plain copy of the backend version? If so, I'd prefer to have it stored in the db directory, where we already have the unchanged keywords.c. All backend extracted sources should be upgradable from pgsql HEAD by simply copying them. 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] CHANGELOG
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 01/05/06 11:41:59 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: CHANGELOG Um, until 1.4 we didn't fill the version number until we really had a release. Since features may move in and out, some might be marked as relased that never will. And they still need removing. This way I have less work at release time, and the notes changes less over time. I don'T understand what you mean. What needs removing? Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] SVN Commit by dpage: r5106 - in trunk/pgadmin3:
Dave Page wrote: md5.c(pp) is unchanged, bar the top comment. md5.h is custom though. I have no problem moving them. Well, thinking again it appears that different from keywords.c md5.c(pp) won't be subject to regular change. So let's leave it as it is now, rollback my previous remarks. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] CHANGELOG
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 01/05/06 15:36:36 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: CHANGELOG I don'T understand what you mean. What needs removing? The features you mentioned that may never get released. Hm? They usually are removed/replaced immediately, not when releasing, no? Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Updated copy patch
Though advised differently, the patch starts with removing the ListView stuff, so I won't look any further at this version. Use the macro, it won't hurt. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 30/04/06 01:44:21 To: pgadmin-hackerspgadmin-hackers@postgresql.org, Dave Pagedpage@vale-housing.co.uk Subject: Lightspeed for frmQuery and other issues. as announced I realized the virtual listview implementation in frmQuery; the code became amazingly slim. Since there's no more data retrieval, the retrieval time shrinks to precisely 0.00 microseconds which should be sufficiently fast to justify omitting this value :-) Cool, nice work. I assume all the clipboard stuff still works? Depends on what you call the clipboard stuff. Everything that worked in 1.4 still works, i.e. single/multiple row copy. To select columns, there's a special syntax to the SELECT command I left grid stuff #ifdef'ed in the source, but it can't work for now. When this is reworked, I'd really appreciate if the interface of ctlSQLResult isn't altered again (there shouldn't be a need to touch frmQuery), and until a different solution is accepted the alternate #define USE_LISTVIEW should remain. If it is fully working, I see no reason to change it again. The only other mod I had in mind was full/multiple row pasting in the edit grid. pasting? At the same time, I noticed how reporting was added to pgAdmin, and was quite horrified. The menu refactoring was done to avoid base class Had a feeling you would be. cluttering, and now it is massively reinvented. Any adding to menu.h is plain wrong for frmMain menu, any code adding in events.cpp (beyond minor submenu handling, i.e. calling enableSubmenu) too, touching base factory classes even more. All reporting stuff should be implemented in frmReport, not in pgObject or so. Please do refactor it using factories. Well the code was modelled as closely as possible on the 'new object' menu code, and given the total lack of comments or other documentaion of the factory code it's not exactly easy to understand either intent or implementation. You could have asked... Here's (from memory) what was done: - The new menu was added using the menu factories, per the new object menu. Reporting isn't comparable to that. See Edit(filtered/lmited)Grid (or the new scripting stuff) - menu ids were added in menu.h because multiple object types need to share specific IDs for the same report. menu ids are supposed to be handled by the factory. - Each object type, via the base class provides it's own menu, per the new object menu. - event.cpp has a minimal handler for the menu. - Each report is produced by the object itself (because that's where the info is, per the main UI views. No, it isn't; its switch-coded in the base class. Certainly ok to add some object specific helper methods to pgXXX classes, but not to create a form from pgObject. - Properties/stats reports etc. Are implemented in pgObject/pgCollection to minimise code duplication. Common methods might go here (AFAICS none is necessary), but the work itself should be done outside. object-CreateReport is the wrong style to do that; in the sense of the menu factory stuff it's an action that's performed on an object, not an object's method. To be precise: pgObject, pgCollection, should be rolled back except for HasXXX helper methods, base/xxx completely. If there's something wrong with any particular part of that you'll need to explain why, and how you think it should be don in a lot more detail, 'cos as far as I can see I've followed existing design pretty closely. No, you did the opposite; you modified base classes that aren't supposed to be touched. To add features like this is what has to be done: - add frmXXX with its factories Every factory (one factory per menu entry!) has - constructor for use in frmMain - CheckEnable (virtual) - StartDialog (virtual) - add instantiating the factories in frmMain - when a new submenu is involved, add enableSubmenu(xxx) to events.cpp. Actually, even touching events.cpp is too much, should done by registering it in frmMain too. I'll refactor that, so that only *one* single core file has to be modified. Since frmQuery et al aren't supposed to be extended too often, the usual MNU_XXX style is to be used there, so MNU_QUICKREPORT is fine. BTW, I wonder why the reporting is creating HTML, not XML. Because XML is good for data exchange, not presentation. You will note that it is XHTML 1.0 Strict though. Isn't XSL/XSLT supposed to deliver the specific rendering? The current implementation looks very special to me, not reusable e.g. for a compilation of multiple reports. Another topic: I realized that the maxRows option (which is obsolete for frmQuery now) is used for some job statistics. I'm not sure if using that limit is a good idea. Regards, Andreas ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL
[pgadmin-hackers] Problem with autocomplete
When triggering autocomplete on spaces (e.g. empty query window), a memory damage will be triggered. If ignored, the full keyword listbox will popup. Happens with VC6, not gtk. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 30/04/06 12:24:08 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: Lightspeed for frmQuery and other issues. Cool, nice work. I assume all the clipboard stuff still works? Depends on what you call the clipboard stuff. Everything that worked in 1.4 still works, i.e. single/multiple row copy. To select columns, there's a special syntax to the SELECT command Then you have some work to finish - both the edit and query grid could copy individual cells, rows, columns or arbitrary groups of cells to the clipboard - functionality that I for one am already using on a regular basis. EditGrid is untouched. copying of arbitrary groups of cells did *never* work correct. The current implementation will omit cells if it doesn't know how to handle it. This is not acceptable: The ctl needs to be rewritten to not accept selections that can't be executed. As I already may have mentioned earlier, I don't intend to spent time on the crappy wxGrid. So if anybody else likes to do so, he/she should pay attention not to change the ctlSQLResult interface for that. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 30/04/06 14:48:08 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: Lightspeed for frmQuery and other issues. EditGrid is untouched. copying of arbitrary groups of cells did *never* work correct. The current implementation will omit cells if it doesn't know how to handle it. This is not acceptable: The ctl needs to be rewritten to not accept selections that can't be executed. I've never run into such a bug, nor has it been reported. How can it be reproduced? Simply select some non-adjacent cells in arbitrary cols and rows. Had it been reported, it would have been looked at of course. As I already may have mentioned earlier, I don't intend to spent time on the crappy wxGrid. So if anybody else likes to do so, he/she should pay attention not to change the ctlSQLResult interface for that. With or without a bug, removing useful functionality is completely unnacceptable. You would be understandably pissed off if a feature you used was removed, and I would ensure the author reimplemented it, or rollback the change. Bug aside, please fix the copy to clipboard to match what was there. The implementation did not meet the primary requirement, so I objected clearly and early. You decided to commit an half-brewn enhancement based on a technique that was known not to meet the TODO, i.e. doing it with a virtual control. You can't be too surprised I basically rolled back that beast, to have the first step made before the second. The reporting stuff is going to frustrate you and me as well. I tried to fix at least the menuing stuff, but had to retract, realizing that you kind-of reinvented the most ugly interaction between the MNU_ enumeration and schema objects acting on that I removed months ago. This basically means that it can't be refactored partially, but essentially needs rewrite. The current implementation style is that of pgAdmin 0.1 to 1.2, which was becoming more and more painful when adding new features. I'm less than inclined to accept having this creeping back in. 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] Lightspeed for frmQuery and other issues.
Dave Page wrote: When asked for further info about *that* todo, you didn't give any helpful answers :-( Well, anybody not knowing how to code a virtual ListView shouldn't start on that... However, I am not complaining about that change - I am complaining that a copy/paste feature was removed - that is unrelated to the virtual listview/grid issue. It wasn't removed explicitely, but the underlying class that didn't meet the requirement was backed out. You've painted the wall before wallpapering it. The reporting stuff is going to frustrate you and me as well. I tried to fix at least the menuing stuff, but had to retract, realizing that you kind-of reinvented the most ugly interaction between the MNU_ enumeration and schema objects acting on that I removed months ago. This basically means that it can't be refactored partially, but essentially needs rewrite. The current implementation style is that of pgAdmin 0.1 to 1.2, which was becoming more and more painful when adding new features. I'm less than inclined to accept having this creeping back in. Like I said, I'll look at changing it to work like the other menus you suggested - but if you're saying the factories cannot do what is required, then they either need fixing, or it can stay as is. It's not a problem of the factories, they do what they should and will work *if used*. But you basically circumvented them, and did all the stuff they're supposed to do once again. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Edward Di Geronimo Jr. wrote: Quoting Andreas Pflug [EMAIL PROTECTED]: Simply select some non-adjacent cells in arbitrary cols and rows. I stated that in the beginning, and asked if anyone had any suggestions on what to do in that case. If you completely arbitrarily hightlight cells, there really isn't a way to store them in the clipboard. Because no one had any suggestions on how to handle it, yourself included, the decision was made to just copy the first group of cells highlighted. I still don't see a need for that extended handling, because the ctl always allowed row selections (and column selections can be achieved from SELECT , a basic SQL feature... ) The implementation did not meet the primary requirement, so I objected clearly and early. You decided to commit an half-brewn enhancement based on a technique that was known not to meet the TODO, i.e. doing it with a virtual control. You can't be too surprised I basically rolled back that beast, to have the first step made before the second. Users dont care about virtual controls or not. They do. It's the speed issue, esp. on non-win32. Users care about basic functionality like being able to copy subsets of data into the clipboard. Only behing able to copy entire rows at a time is a half brewn implementation. It would have been much easier for you to refactor things into a virtual table Wrong. Look at the current implementation, which basically takes version 5021 and *removes* 100 lines of code. Also, you're forgetting that the only reason I didn't implement code similar to this originally is because you were rather insistant that the data retrieval code should not be changed in any way. It's not exactly reasonable to place restrictions on other people's work simply so that you can later complain that the work isn't good enough and have an excuse to rip it out. Not quite, I always insisted on doing it the virtual way and made quite clear that I'd enforce it. Explaining how to do it required more work than to do it, I said that earlier. See how it works now, and do it with wxGrid if you like. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Edward Di Geronimo Jr. wrote: Quoting Dave Page dpage@vale-housing.co.uk: Pasteing? I dunno. Anyway in MS Query Analyser you can paste entire rows, or sets of new rows into a table. I had been planning on looking at something similar, but with an additional option (offered at paste time, when necessary) to skip OID/serial columns. Enterprise Manager handles the issue by skipping over any identity (serial) columns when pasting rows. That's how I figured it should be done. OID's would of course be treated the same way. I was also planning on looking into it when I had a chance to get back to pgAdmin. If you want, I should be able to look into it midweek or so. Let me know if you want to do it or if I should. So this was a frmEditGrid issue, not frmQuery. I didn't touch that. Please note that there are many editing issues here (very platform specific), which is, I know it's boring to read again, a wxGrid issue. 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] Problem in graphical explain
Miha Radej wrote: Hi! I have some tables and playing with a query and graphical explain got me to a strange result - a grey line across the entire window; see http://mcajvar.prkoritu.net/pgadmin/graphic_explain_db1.png . Ok Miha, apparently the problem is triggered by multiline filters. I added an option to pgAdmin (svn) that allows graphical display of a loaded analyze output, the multiline issue is fixed now. Please try svn. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 30/04/06 16:19:51 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: Lightspeed for frmQuery and other issues. It wasn't removed explicitely, but the underlying class that didn't meet the requirement was backed out. You've painted the wall before wallpapering it. Quickreport sat over that class as well - is that now broken too? That's in frmQuery only, right? If so, the local solution is fine. If it's more global, it should go somehow to dlgClasses. Please restore the functionality or I will back out the patch until it is completed in it's entirety. Which functionality? You complain about the work that led to significant speed increase from the original code, but at least we busted a gut to make sure it didn't break any existing functionality. Again: I said early enough the base was wrong. And I didn't see *any* speed increase on linux. Probably, any virtual solution will be ok, but any non-virtual solution *cant* be ok. It's not a problem of the factories, they do what they should and will work *if used*. Like I said, I'll look at this. I didn't grok that the failed attempt you mentioned was only a minor rejig. It should have been, but things are horribly intervowen. I'd have to understand in detail what's going on to continue, because apparently removing MNU_XXX entries would kill methods too. 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] Lightspeed for frmQuery and other issues.
Edward Di Geronimo Jr. wrote: Quoting Andreas Pflug [EMAIL PROTECTED]: I still don't see a need for that extended handling, because the ctl always allowed row selections (and column selections can be achieved from SELECT , a basic SQL feature... ) Very often in my work, I would not know exactly what columns I need the data from until after I see the results of the query. Someone would walk into my office and say What's wrong with Joe Smith's account? I'd run a query to get an overview of the account, and what columns I needed would change depending on what looked to be wrong. It's a lot easier to click on the cell I need and hit copy than to run another query to narrowing things down. Users dont care about virtual controls or not. They do. It's the speed issue, esp. on non-win32. The implementation I did was 4x faster than the old implementation, which apparently had been acceptable for a long time, but also offered more features. There was no tradeoff to that work, unless you had a phobia of grids. Yes I do have a wxGrid phobia. Making the frmEditGrid 80 % solution to 90 % was painful enough, and things tend to not get easier on the last 10 %. If you like fixing it in frmEditGrid, fine. The main speed issue was on gtk, and my small 1k row testcase did *not* show improvement. The current solution is ok for 10^n rows, as long as libpq and the OS can handle it. All previous versions, including yours, simply stalled. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: Yes, but it used wxGrid methods to build the report, thus, like the copy functionality, would have needed fixing to work with a listview I already changed that to the new interface. (actually, frmReport has a listview-reporttable method that could be used). I don't quite understand that. The ability to copy columns and arbitrary groups of cells as well as rows. Again: I said early enough the base was wrong. And I didn't see *any* speed increase on linux. Probably, any virtual solution will be ok, but any non-virtual solution *cant* be ok. The point was that it was a distinct improvement, even if not the ultimate solution - anyway, that's irrelevant now so let's move on. An improvement that ignores basics is useless. It should have been, but things are horribly intervowen. I'd have to understand in detail what's going on to continue, because apparently removing MNU_XXX entries would kill methods too. Are you doing this or me? I'm happy to work on it if you'll provide feedback when needed. If you're doing it though, let me know and I'll do something else. Since most of the work is specific, you'd better do it. I can assist with menu/general stuff, which should reduce to some new reportSomethingFactory in frmMain::CreateMenus(). Submenus are now handled automatically, so even the events.cpp is totally generic now. I'm going to extend programmers-readme.txt ASAP. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-hackers] programmers-readme.txt
Hm, I could have sworn that I already added programmers-readme.txt months ago to svn. Anyway, please review it if it makes sense to you. Regards Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Lightspeed for frmQuery and other issues.
Dave Page wrote: -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 30/04/06 18:44:01 To: Dave Pagedpage@vale-housing.co.uk Cc: pgadmin-hackers@postgresql.orgpgadmin-hackers@postgresql.org Subject: Re: Lightspeed for frmQuery and other issues. (actually, frmReport has a listview-reporttable method that could be used). I don't quite understand that. void frmReport::AddReportTableFromListView(ctlListView *list); Ok, I see that method, and see it used 4x in pgObject, but dunno what it's about. A quick glance makes it appear strange to me, as all xxReportYY methods in pg* files. Can't comment on what they're doing. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Commits 5097(1.4 branch) and 5096(trunk) break
Florian G. Pflug wrote: Hi Starting from revisions 5097 (for 1.4) and 5096 (trunk) the OSX build failes for me. Seems like ::GetLastError() is undefined when using wxMac 2.6.2. Any ideas? Man, you really should upgrade your operating system to a compatible one... :-) GetLastError is a win32 api call, needs to be removed. 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
[pgadmin-hackers] Lightspeed for frmQuery and other issues.
Hi Dave, as announced I realized the virtual listview implementation in frmQuery; the code became amazingly slim. Since there's no more data retrieval, the retrieval time shrinks to precisely 0.00 microseconds which should be sufficiently fast to justify omitting this value :-) I left grid stuff #ifdef'ed in the source, but it can't work for now. When this is reworked, I'd really appreciate if the interface of ctlSQLResult isn't altered again (there shouldn't be a need to touch frmQuery), and until a different solution is accepted the alternate #define USE_LISTVIEW should remain. At the same time, I noticed how reporting was added to pgAdmin, and was quite horrified. The menu refactoring was done to avoid base class cluttering, and now it is massively reinvented. Any adding to menu.h is plain wrong for frmMain menu, any code adding in events.cpp (beyond minor submenu handling, i.e. calling enableSubmenu) too, touching base factory classes even more. All reporting stuff should be implemented in frmReport, not in pgObject or so. Please do refactor it using factories. BTW, I wonder why the reporting is creating HTML, not XML. I added a scripting option, which will (for std. objects) call the query tool with reengineered script as usually performed with the sticky bit set. IMNSHO we can drop the option now, because both behaviours are now available at the same time. Scripting of SELECT, INSERT and UPDATE (typing the col names can be boring) coming soon. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Visual C++ 2005
Magnus Hagander wrote: Sounds like distri bloating, for no benefit. Best would be if this manifest stuff could be omitted totally; we probably could link to the old msvcrt then. The bloat is only about 1.5Mb which isn't too bad, but having Or you can just link statically and then only pull in the parts you need? Not the worst solution. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Visual C++ 2005
Dave Page wrote: -Original Message- From: Hirodhi Saito [mailto:[EMAIL PROTECTED] Sent: 21 April 2006 16:36 To: Dave Page; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Visual C++ 2005 Now that Visual C++ 2005 Express Edition is free from Microsoft, is there any reason not to upgrade the VC project files to the latest version and drop VC++6 support? I think VC++6 environment is required until it stops supporting W2K. Why? Apparently, VC2005 links mandatorily/unavoidable to .NET CRT libs which aren't necessarily present on the system, and which should not be delivered with the app (according to MS). If this wouldn't be the problem, we'd have VC2005 projects in svn for some months now... 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] Visual C++ 2005
Hirohi Saito wrote: I think VC++6 environment is required until it stops supporting W2K. Why? It has difficulty in offer by the MSVCRT problem. Probably, In the case of supply of a binary. There's a typo in your email name BTW: Hirodhi Saito Ahhh, even not only environment but my name will be unstable recently.:-) We all know that Japan's ground may be shakey frmo time to itme. Apparently, letters can be affected too. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Visual C++ 2005
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 21 April 2006 17:07 To: Dave Page Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Visual C++ 2005 Why? Apparently, VC2005 links mandatorily/unavoidable to .NET CRT libs which aren't necessarily present on the system, and which should not be delivered with the app (according to MS). Ah, now that I didn't know. So, you're expected to distribute the entire .NET Framework just to get msvcrt8.dll (or whatever)? Urgh. Somewhat. Those dlls are expected in Windows\WinSxS\something. I suspect that pgAdmin *would* work if we just shipped that DLL side by side though, but I'm wary. 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] Visual C++ 2005
Dave Page wrote: I'm not so sure it's a problem - from Visual Studio's redist.txt: For your convenience, we have provided the following folders for use when redistributing VC++ runtime files. Subject to the license terms for the software, you may redistribute the folder (unmodified) in the application local folder as a sub-folder with no change to the folder name. Sounds like distri bloating, for no benefit. Best would be if this manifest stuff could be omitted totally; we probably could link to the old msvcrt then. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Visual C++ 2005
Dave Page wrote: The bloat is only about 1.5Mb which isn't too bad, but having just watched literally thousands of warnings go past when compiling wxWidgets about all sorts of stuff like strdup being deprecated, I really can't be bothered to carry on. Perhaps when wx is cleaned up... According to MS, C++ is deprecated... There's a pragma for that. This warning is simply stupid for us, IMHO no reason for wx clean up. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Clipboard update
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 12 April 2006 04:48 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] Clipboard update Here's a small update to the clipboard support. It adds an option to allow using Tab as the column separator. Using tab as the separator allows you to paste the results into Excel and OpenOffice Calc while retaining the columns. I haven't had the chance to test it, but I think it will also allow you to paste rows into SQL Server's Enterprise Manager. Thanks Ed, patch applied. We should probably consider making the default copy settings be tab deliminated with no quoting, as that's how both Excel and the SQL Server tools put data into the clipboard. That's fine with me - does anyone object? Only for copy/paste; in files tab is crap Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Problem in graphical explain
Miha Radej wrote: Hi! I have some tables and playing with a query and graphical explain got me to a strange result - a grey line across the entire window; see http://mcajvar.prkoritu.net/pgadmin/graphic_explain_db1.png . There's something wrong here :-) I then made an exact duplicate copy of the users, database, everything I could think of and tried to duplicate the strange display. But the problem wouldn't occur in this local copy; see http://mcajvar.prkoritu.net/pgadmin/graphic_explain_db2.png . Does pgAdmin use the output of the explain query in order to construct the graphic illustration? It does. If so then these may be helpful: This yields foo graphics: Nested Loop (cost=0.00..0.01 rows=1 width=485) Join Filter: (outer.id = inner.id_eventi) - Seq Scan on eventi t1 (cost=0.00..0.00 rows=1 width=12) Filter: ((datum = '2006-04-12 00:00:00'::timestamp without time zone) AND (datum = '2006-05-12 00:00:00'::timestamp without time zone) AND (prikaz = 1::smallint)) - Seq Scan on eventi_vsebina t2 (cost=0.00..0.00 rows=1 width=477) Filter: (narocilnica = 1::smallint) This yields a nice illustration: Nested Loop (cost=0.00..47.26 rows=1 width=485) Join Filter: (outer.id = inner.id_eventi) - Seq Scan on eventi t1 (cost=0.00..35.38 rows=1 width=12) Filter: ((datum = '2006-04-12 00:00:00'::timestamp without time zone) AND (datum = '2006-05-12 00:00:00'::timestamp without time zone) AND (prikaz = 1::smallint)) - Seq Scan on eventi_vsebina t2 (cost=0.00..11.88 rows=1 width=477) Filter: (narocilnica = 1::smallint) Hm, don't see why this clashes, something wrong with cost=0? Will have to debug this some day. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] [pgadmin-support] Feature request - option
Dave Page wrote: On 5/4/06 17:44, Miha Radej [EMAIL PROTECTED] wrote: Hi! I've been playing around a bit with this and I am sending attached a patch which Works For Me(tm). Since this was my first stab at anything such as this, I do hope it isn't too horrible :) The thought was to provide a configure option with which to disable installation of non-pgAdmin documentation: PostgreSQL and Slony docs. With the switch omitted, all the documentation should install. Like I said, this works for me, I've played around a bit and it Seems To Work(tm) :) Hi Miha, Looks good to me in principle - my only thought is that --disable-docs should probably disable all docs, not just the slony and PG ones. Perhaps --disable-external-docs? Agreed. A pgadmin-doc-only-without-pg-and-slony option would require a different help index file without pg or slony references. 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
[pgadmin-hackers] Query grid
After several weeks I succeeded in reconnecting my win32 machine and have a look at pgadmin stuff again. I fired up the query tool and my first impression was can we have this a little less ugly please? when I saw those grey spaces. Is the tool expected to display up to 10G of rows? I remember the comment how fast this should have become, so I tried SELECT * from pg_attribute on a small db. I had 3614 rows in 600+1400ms on a pre-grid version (ancient 700MHz Athlon), and 720 rows in 600+47000ms on the grid version, with 2894 rows dropped I killed another attempt after 5 minutes. IIRC, Edward mentioned he used the original wxGridTable implementation because it worked good for him, and consequently I didn't find any SetTable() call. As I mentioned earlier and , an inevitable requirement is the usage of virtual row/col management, to improve performance on larger resultsets. The new ctlSqlGrid fails to implement it, and thus fails even on result sets that can't really be called big. This implementation is clearly a bad regression. Please revert ASAP and come back with a non-grid version (virtual listbox or listview), I still fail to see any advantage of wxGrid for this usage. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query grid
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 April 2006 14:22 To: [EMAIL PROTECTED]; Dave Page Cc: pgadmin-hackers Subject: Query grid After several weeks I succeeded in reconnecting my win32 machine and have a look at pgadmin stuff again. I fired up the query tool and my first impression was can we have this a little less ugly please? when I saw those grey spaces. Is the tool expected to display up to 10G of rows? Well, those ugly grey spaces look identical to those in your View Data code so any fix should be applied to both controls. I remember the comment how fast this should have become, so I tried SELECT * from pg_attribute on a small db. I had 3614 rows in 600+1400ms on a pre-grid version (ancient 700MHz Athlon), and 720 rows in 600+47000ms on the grid version, with 2894 rows dropped I killed another attempt after 5 minutes. Yes, it was much faster. See the benchmarks I posted to the list at http://www.pgadmin.org/archives/pgadmin-hackers/2006-02/msg00155.php [For a 100,000 row query] 52.277 Secs + 9.123 Secs (v1.5, with your patch) 52.276 Secs + 39.688 Secs (v1.4.1) However, I am seeing dismal performance today, so something has got borked at some point. IIRC, Edward mentioned he used the original wxGridTable implementation because it worked good for him, and consequently I didn't find any SetTable() call. As I mentioned earlier and , an inevitable requirement is the usage of virtual row/col management, to improve performance on larger resultsets. The new ctlSqlGrid fails to implement it, and thus fails even on result sets that can't really be called big. Originally it was a virtual table, however it was found to be faster yet to use the built in table. I wonder now however, if when I tested the later version of the patch I was actually testing the wrong version. Maybe that needs to be reimplemented. The builtin table can *never* be faster than a clean virtual implementation. This implementation is clearly a bad regression. Please revert ASAP and come back with a non-grid version (virtual listbox or listview), I still fail to see any advantage of wxGrid for this usage. It has been proven to be significantly faster. I will not revert the patch unless it proves impossible to fix the problem you are seeing, which seems unlikely given the speedup which I saw on the earlier versions. Reverting every patch because it is found not to be perfect when first applied would be a very good way of ensuring that nothing ever gets done. IMNSHO this patch is rotten from the ground. wxGrid is known to be flakey, extending its use is a bad idea. The speed issue is not a question of grid or non-grid, it's a question of virtual data/display management. 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 grid
Dave Page wrote: and we've already seen that the grid can be significantly faster than the list. This is plain wrong. I never said the current listview implementation is good; it isn't. But to rewrite it with wxVIRTUAL or however the style is called is for sure easier than doing it with wxGrid. Actually you've said on a number of occasions that the current implementation is limited by the OS's underlying controls; for example: Yes, when using the non-virtual versions. They're managing their data most ineffectively. That's why the TODO item is there for ages now. If the current implementation isn't rewritten, I'll commit a virtual rewrite of wxListView based ctlSqlResult (as soon as I find the time, which will certainly not be this week). It will probably require more work on frmQuery (remove the ctl filling loop, no need for the second timing display) than on the ctl itself, making it incompatible to ctlSqlResult implementations that are not managing their data virtually. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query grid
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 April 2006 16:06 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] Query grid If the current implementation isn't rewritten, I'll commit a virtual rewrite of wxListView based ctlSqlResult (as soon as I find the time, which will certainly not be this week). It will probably require more work on frmQuery (remove the ctl filling loop, no need for the second timing display) than on the ctl itself, making it incompatible to ctlSqlResult implementations that are not managing their data virtually. Yeah, well hold fire on that - I just found what broke it, and now get (second of 2 runs in each version, from the same server): 1.5.0: -- Executing query: select * from pbx_log limit 1 Total query runtime: 8187 ms. Data retrieval runtime: 1062 ms. 1 rows retrieved. A correct implementation has *no* retrieval time, just some microseconds of setting up the virtual control. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Query grid
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 03 April 2006 16:40 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] Query grid A correct implementation has *no* retrieval time, just some microseconds of setting up the virtual control. Unless I'm misunderstanding, what you would like to see is a class derived from wxGridTableBase which is attached to the grid using SetTable()? If so, that is exactly what Ed implemented originally, and it *was* slower than what is there now. Then the implementation was wrong. ATM I'm not sure if wxGridTableBase has virtual methods, and if it had I wouldn't trust them. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query grid
Edward Di Geronimo Jr. wrote: Andreas Pflug wrote: A correct implementation has *no* retrieval time, just some microseconds of setting up the virtual control. Do you have any advice on how exactly to implement that behavior? It looked like the View Data grid did it by only retrieving the actual results as they were needed. When I started on this, you were rather firm that the way the results were retrieved should not be altered in any way. If you want, I'll look into merging the virtual table from the View Data grid with the results grid. As I said in an earlier mail, I'd expect more work on frmQuery than on ctlSqlResult(wxListView) to make it virtual. Implementing it will be probable faster for me than explaining what to do. I'm short on time, so if you insist on using wxGrid you're on your own. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Tabbed Query Analyzer
Nicholas Walker wrote: Just wondering if there has been a feature request for a tabbed query analyzer. Not inside of the main application, but whenever you request a new query analyzer window instead of opening a new window, just have a new tab, in the query analyzer window. Any thoughts. That's not feasible. We already have 4 tabs for a _single_ query. Nobody can handle a multiple of that. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Import from CSV - Questions
Magnus Hagander wrote: Magnus, any chance of getting a look at what you currently have to help guide me in the appropriate direction? Umm. That would kind of assume it's written down in a comprehensible way. Which it isn't, of course :-) The general ideas so far have been, off the top of my head: * Pluginnable set of readers and writers. Originally I'd see postgresql, odbc, xml and possibly csv. Pg driver would be optimised to use COPY when available. * Pluginnable set of transforms that would operate on the rows. By default things like copy and concatenate and maybe regexp. Future enhancement would be a python extension, as Dave mentioned. (Or really, anything else) * I was envisioning a split of say package, job, step (terms of course subject to discussion). package basically a set of job, job a set of steps. Things like connections would be defined at the job level, along wiht parmaeters for transaction control etc. (So you can use it to transfer 10 different tables within a single transaction, something I need all the time). * I'd like to see the job format stored as XML with a well defined schema, so different appliations can generate it - both manually (GUI-wise from pgadmin and phppgadmin etc) and automatically. * The engine should be available both as a commandline tool (which must not require X libraries etc, because it should be deployable everywhere) and as acommand inside pgadmin (like MS DTS) Um. I think that's about it. I had some sketches of classes and interfaces around (not complete, but an idea), but I can't find them :( This sounds like an awful lot of work. A somewhat reduced version (IIRC Dave and me discussed something like the following briefly) a more raw import (maybe into temp tables) could be a big step, giving the admin the chance to create views on that tables that do the extractions he likes. PostgreSQL already has all functions you'd like, no need to reimplement them. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgadmin-hackers] some topics
[EMAIL PROTECTED] wrote: Author: dpage Date: 2006-03-07 09:45:31 + (Tue, 07 Mar 2006) New Revision: 5047 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5047view=rev Log: Update for 1.4.2. Note that pgAdmin works with Mammoth PostgreSQL from Command Prompt. Did anybody check with EDB recently? I don't know about possible extensions since the first release. I saw the coverty involvement on -hackers, IMHO we should jump on that train too. 7 lines are worth some bugs :-) 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] some topics
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 07 March 2006 10:34 To: Dave Page Cc: pgadmin-hackers@postgresql.org Subject: some topics [EMAIL PROTECTED] wrote: Author: dpage Date: 2006-03-07 09:45:31 + (Tue, 07 Mar 2006) New Revision: 5047 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5047view=rev Log: Update for 1.4.2. Note that pgAdmin works with Mammoth PostgreSQL from Command Prompt. Did anybody check with EDB recently? I don't know about possible extensions since the first release. That's a good point. Anyone got a copy kicking about? I saw the coverty involvement on -hackers, IMHO we should jump on that train too. 7 lines are worth some bugs :-) It can't hurt to ask - they already test wxWidgets (http://scan.coverity.com/). Noticed that. Will you put your project leader hat on and ask? Should be both of us to have access to the result. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] some topics
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 07 March 2006 10:40 To: Dave Page Cc: pgadmin-hackers@postgresql.org Subject: Re: some topics Noticed that. Will you put your project leader hat on and ask? Should be both of us to have access to the result. Sure - I haven't taken it off yet this morning so I'll get right on it! You can leave your hat on :-) Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query results in grid, new patch
Florian G. Pflug wrote: .) Could the initial size of the columns be choosen so, that the captions are not cut off? Or, even better, pgadmin could remember the with of the columns between selects, at least if the captions stay the same... The old control's behaviour was like that. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query results in grid, new patch
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 06 March 2006 09:42 To: Florian G. Pflug Cc: Dave Page; Edward Di Geronimo Jr.; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query results in grid, new patch Florian G. Pflug wrote: .) Could the initial size of the columns be choosen so, that the captions are not cut off? Or, even better, pgadmin could remember the with of the columns between selects, at least if the captions stay the same... The old control's behaviour was like that. Yes, it was, but it might be a nice fix. It's bugged me for a while. Hu? I meant the control *does* remember column sizing for repeated execution of similar queries since 1.2!!! This is not a nice fix, it is *required*. I don't give a cent for copy/paste from the result (in 10 years on SQL RDBMS, I might have done that 5 times), I need repeatable results from query tuning. Trying to autosize the column from content doesn't work satisfying. 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 results in grid, new patch
Dave Page wrote: -Original Message- From: Florian G. Pflug [mailto:[EMAIL PROTECTED] Sent: 06 March 2006 03:37 To: Florian G. Pflug Cc: Dave Page; Edward Di Geronimo Jr.; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query results in grid, new patch I've finally come around to testing the new grid on osx, I must say that I'm really impressed. It seems much more responsive than the old one to me, and being able to copy rows, cols and fields to the clipboard really rockts. I have to rather small suggestions, though .) Ctrl-A (or Cmd-A on OSX) should select the whole table - it's a rather well established UI-standard I believe to let Ctrl-A/Cmd-A select the whole whatever you are currently editing. Fixed. .) Could the initial size of the columns be choosen so, that the captions are not cut off? Possible todo for anyone that wants to try it! NOT a todo. I found the result something between annoying and useless when I implemented column sizing preserving, esp. in case of many columns. I still didn't have the time to have a look at the patch, and I will be very unhappy if I find the result a regression because its functions are extended in a direction the control never was intended and designed for. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Query results in grid, new patch
Dave Page wrote: On 6/3/06 19:04, Andreas Pflug [EMAIL PROTECTED] wrote: Dave Page wrote: NOT a todo. I found the result something between annoying and useless when I implemented column sizing preserving, esp. in case of many columns. I still didn't have the time to have a look at the patch, and I will be very unhappy if I find the result a regression because its functions are extended in a direction the control never was intended and designed for. If you find any breakages then do report them and I will look at them, but please do not forget that pgAdmin is not designed entirely for your usage patterns - just because you don't copy'n'paste query results doesn't mean there aren't a thousand people that do (or will do). We have discussed this previously. Trying to extend the query tool to a multi purpose data manipulating tool is a dead end. Finally, don't forget: My initial impulse to code on pga3 was dissatisfaction with pga2's query tool, so I'm most sensitive on that topic. 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] 1.4.2?
Dave Page wrote: Seems to me we might be about ready for 1.4.2. Any objections? If not, I'll look at wrapping it sometime next week. Go. 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] missing translation strings?
Miha Radej wrote: there is no sign of the string i searched for in any of the translation files, only in the code. should i manually extract the strings (generate the .pot catalogue) first? iirc this was being done automatically in the past, along with updating the .po files, wasn't it? We don't create the pot file regularly, but usually only before releases to avoid lots of strings going in and disappearing again. I'd suggest you stick to the current status. If you're creating your own pot, you might translate strings that are dropped/changed just a few days later. 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 results in grid, new patch
Dave Page wrote: Note to Andreas: unless you have any concrete technical reasons why this patch should not be applied, I'm fully intending to accept it once the current wrinkles are ironed out. Please shout now rather than later!! I won't find time to review it before the weekend. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] localpipe
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Eisentraut Sent: 24 February 2006 09:45 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] localpipe pgAdmin talks about a localpipe, but the thing is in fact a local socket, not a pipe. I suggest the following change. Hm, easily mixed up with localhost, which uses a socket too. But we don't have the space for 'local unix socket' either. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] German translation
Peter Eisentraut wrote: I went through the German translation and removed some excessive anglicisms and made some other corrections. Hm, I had a glance at what you changed, and I agree only partially. It's certainly horrible German style to omit the Bindestrich, I must admit that (thou in many cases, writing it in one word is the really correct style). But I'm still in favour for ß instead of ss... :-) I intentionally left many english terms, as file, key, query, which I wouldn't count as anglicisms but simply well-known technical terms. Too many translations may make the description less understandable (for this reason, I use english OS and server versions exclusively), so I tried to find a compromise. We didn't have feedback on this from users so far (except for valid complaints about flakey and weird translations). In some cases, the translation will be far too long. Auto FK index may not get much longer, I'm afraid there's no good abbrevation for Fremdschlüssel, see the foreign key dialog. Ich frach mich grade wieso ich das eigentlich englisch schreibe... :-) Gruß, 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] German translation
Peter Eisentraut wrote: Andreas Pflug wrote: I had a glance at what you changed, and I agree only partially. It's certainly horrible German style to omit the Bindestrich, I must admit that (thou in many cases, writing it in one word is the really correct style). But I'm still in favour for ß instead of ss... :-) The Rat für deutsche Rechtschreibung was in session today, so you should have phoned in. :-) Yes, indeed. I'm a little upset they didn't :-) Still, we're free to decide, and we have quite a mixture now. While that is debatable, the terms I changed were almost all used inconsistently (which was the reason I started to work on this in the first place -- using Query and Abfrage in two adjacent buttons isn't good style no matter what), so that argument doesn't have much weight anyway. That said, I will gladly refer you to German database literature, which I regularly use as reference for translations. I don't read books, German DB books even less... I don't understand them (too many unknown terms). What's your proposal on Auto FK index? Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query tool results in grid
Dave Page wrote: -Original Message- From: Edward Di Geronimo Jr. [mailto:[EMAIL PROTECTED] Sent: 21 February 2006 03:03 To: Andreas Pflug Cc: Dave Page; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query tool results in grid This problem is partly alleviated by handing the double timing display, Not really. This is *the* major issue on the query tool. Huh? I said speed is the problem, for which the timer partly helps by seperating the query/transfer time from the display time. What are you saying is the problem? Hm, apparently we have the word omission issue again... IMNSHO the timing issue isn't really allevated, but remains as the major issue. *How* that is implemented is another issue. I suspect that Andreas means he wants it encapsulated into ctlSqlResult, overriding the existing data population methods, rather than an extra layer of complexity between the data retreival code and ctlSqlResult. What I mean is: Recoding ctlSqlResult based on the current wxGrid seems a waste of time to me. We're currently using wxGrid for View Data, and have enough problems with it to get its in-line editing to work. Marking for copying appears still non-flawless to me too. While it certainly is a good idea to have a super ctlSqlResult2 or something, based on wxGrid2 or whatever, that's capable of handling all our needs for View Data or the Query Tool, the current base classes don't seem appropriate. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgAdmin server properties dialog
Peter Eisentraut wrote: I have a few comments on the server properties dialog on issues that have bothered me for a long time. First, the title of the window is something like Server localhost, which means nothing. Perhaps this should be Connection Properties or Server Properties. When I read Description I think of sentence or paragraph length descriptions (cf. ODBC data sources). Perhaps Name is better. Then, the term Address is a bit confusing. PostgreSQL tools typically use the terms host, port, username, database. So please use Host here, too. The Service field is unclear to me and it clashes with the termin service as applied by libpq. See concurrent discussion on pgsql-hackers. store password should be capitalized. Overall, the arrangement of the fields could be optimized. The Description field is something that the user makes up whereas the other ones are necessitated by the environment, so it would be sense to group them together that way. Also, host and port should be closer together. I imagine this would be better: Name: Host: Port: SSL: Username: Password: Store Password: Maintenance DB: Service(?): Connection Now: I'd propose to use Host address to make it a little clearer. The word Service is, as Dave already pointed out, the correct one under Win32. However, it's certainly not very meaningful under *ix, so how can we call this? In theory, we could name the field different in the win32 and the *ix versions (they can control only local servers), but this also affects the documentation so a common name for all versions would highly desirable. I would also welcome as a click-saving measure that Connection Now be transformed into a button. So replace the OK buttong by, say, Save and Save and Connect. Easier said than done. The OK button is handled generalized in a class deep down, but it's doable (this applies to new registrations only, for editing existent ones it's still ok). Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] select inside transactions
Magnus Hagander wrote: I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. Yikes. I guess my disclaimer was well placed ;-) Did you just revert it, or did you figure out a proper way of doing it? Just reverted. Currently I don't see a proper way to implement it, unless multiple output panes (as in isqlw) are implemented. Bummer. I had that feeling - it seemed to easy :-( You could try to store the last result (for later returning), and drop it if a newer is detected. Please take care that return code of *all* commands are reported. 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] detecting serials in 8.1
Kris Jurka wrote: Andreas Pflug wrote: Kris Jurka wrote: Actually it turns out that whether the schema gets in there or not depends on the search path when the table is created. That's what pgSchema::GetPrefix does too. That's fine as long as you assume that the search path never changes and as long as you only have one schema in your search path. I don't think these are assumptions we can make. It's _always_ fine, because GetSchema obeys the search path and the reengineered SQL is meant to be used in a search path situation as it was at the time of reengineering. There are plenty of other situations where the reduced form (omitting search-pathed schema) won't work. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool results in grid
[EMAIL PROTECTED] wrote: I've attached a preliminary patch to display the results of the Query Tool using a grid control instead of a list. Sorry to frustrate you, but using the grid is provenly even more ineffective (on _all_ platforms) than the current one. wxGrid is known to degrade drastically for bigger sizes. That's why View Data uses its own implementation of wxTable. In general, wxGrid is an ugly piece of code difficult to handle, wx-dev have plans to rewrite it from ground for good reasons. We need a rewrite of ctlSqlResult, but it must base on a virtual wxListBox or wxListView, i.e. maintaining the data ourselves. On the long run, extending ctlSqlBox to use it in View Data would be desirable. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] detecting serials in 8.1
Kris Jurka wrote: Andreas Pflug wrote: It's _always_ fine, because GetSchema obeys the search path and the reengineered SQL is meant to be used in a search path situation as it was at the time of reengineering. There are plenty of other situations where the reduced form (omitting search-pathed schema) won't work. Let me back up and make clear what I'm saying. The code I originally submitted is not correct. The code you committed is not correct either. To correctly determine what the default value for a serial will look like, you need to know what the search_path was at table creation time. Knowing its current value is not relevent. Run the following in psql. SET search_path TO public; CREATE schema s1; CREATE TABLE s1.t1(a serial); SET search_path TO s1; CREATE TABLE s1.t2(a serial); \d t1 \d t2 Note how one default includes the schema and the other doesn't. Explain how pgadmin can correctly determine the default value for both of these tables. The problem of non-standard serials using pg_depend is on the TODO-list. AFAICS the current implementation is better than before, and I don't think adding more brains to this inferiour pattern matching approach wouldn't make things better. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgadmin-hackers] select inside transactions
I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. 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] SVN Commit by dpage: r5000 - in trunk/pgadmin3:
Kris Jurka wrote: [EMAIL PROTECTED] wrote: Author: dpage Date: 2006-02-17 10:49:24 + (Fri, 17 Feb 2006) New Revision: 5000 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5000view=rev Log: Properly escape single quotes in connection strings. This commit generates a warning all over the place: Fixed in svn, thanks for reporting. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] select inside transactions
Magnus Hagander wrote: I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. Yikes. I guess my disclaimer was well placed ;-) Did you just revert it, or did you figure out a proper way of doing it? Just reverted. Currently I don't see a proper way to implement it, unless multiple output panes (as in isqlw) are implemented. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] SVN Commit by dpage: r5003 - in trunk/pgadmin3:
Kris Jurka wrote: [EMAIL PROTECTED] wrote: Author: dpage Date: 2006-02-17 11:05:34 + (Fri, 17 Feb 2006) New Revision: 5003 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5003view=rev Log: Mask the password when logging the connection string. This crashes for debug builds. Need to use .c_str() on the cleanConnStr. Hmpf, seems we had a small testing problem on the last patches... Fixed in SVN, thanks for reporting. 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] detecting serials in 8.1
Kris Jurka wrote:
8.1 has changed the default text for serials from something like
nextval('public.tab_col_seq'::text) to nextval('tab_col_seq'::regclass)
Applied with editing (didn't check for schema).
+ // Technically this serial check can still fail for sequences that
+ // get created with non-default names. Consider:
+ // CREATE SEQUENCE st_a_seq;
+ // CREATE TABLE st (a serial);
+ // Now the default's sequence is actually st_a_seq1.
This can't be created consistently using the CREATE TABLE foo (bar
serial) syntax, instead the column default syntax would need to be used.
I've put this on the TODO list, we'd need some discussion what reverse
engineering we really should show in such cases. This also has to
correspond with our column dialog, which will add pg_depend
automatically if adding a serial to an existing table (thus mimicking
the CREATE TABLE ... SERIAL stuff).
Regards,
Andreas
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] detecting serials in 8.1
Kris Jurka wrote:
Andreas Pflug wrote:
Kris Jurka wrote:
8.1 has changed the default text for serials from something like
nextval('public.tab_col_seq'::text) to nextval('tab_col_seq'::regclass)
Applied with editing (didn't check for schema).
Actually it turns out that whether the schema gets in there or not
depends on the search path when the table is created.
That's what pgSchema::GetPrefix does too.
Regards,
Andreas
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgadmin-hackers] Change password issue
Dave Page wrote: On the TODO list. It is? Can't see it for looking :-( I meant _Let's put it_ on the TODO list. Apparenly abbrevations and omissions might lead to decreased understandability :-) Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgadmin-hackers] Query favourite comment
After quite a while, I finally found the time to package a win32 snapshot. Some comments: 1) apparently, we need two iconv dlls now: iconv.dll for xml2 and libiconv-2.dll for libpq. Hm... 2) When adding a favourite, the whole buffer is taken, not just the marked area. This differs from the usual pgadmin behaviour (except save as). 3) I would have expected more than just a multiple clipboard function. Why isn't the query executed immediately? Why does it replace the buffer completely? Why not just executing it, or insert at current selection? 2) and 3) mean no real advantage over distinct sql files (actually: less function, because once stored, a favourite can't be edited any more), to the expense of additional dependencies. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query favourite comment
Magnus Hagander wrote: Can we link iconv statically? (That's what I did for my tests, that's probably why I didn't notice it) I'm a friend of static linkage, esp. if only a small fraction of a dll's functions are used. As for the replace vs. insert issue, when I tested it it asked me if I wanted to replace the query and gave me yes/no/cancel options, with No doing an insert. That's what it's supposed to do. If it doesn't, then something is weird. Which makes me complain about those message boxes, forgot this in my prev mail. I see quite a lot of them popping up when using favourites. In general, I find do you want to do that msg boxes very annoying. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Query favourite comment
Dave Page wrote: -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: 13 February 2006 14:01 To: Dave Page; Andreas Pflug Cc: pgadmin-hackers Subject: RE: [pgadmin-hackers] Query favourite comment After quite a while, I finally found the time to package a win32 snapshot. Some comments: 1) apparently, we need two iconv dlls now: iconv.dll for xml2 and libiconv-2.dll for libpq. Hm... I suspect we can get down to one by compiling libxml2 ourselves, however that would probably make building pgAdmin far more difficult. Lesser of two evils 'n' all that... Can we link iconv statically? (That's what I did for my tests, that's probably why I didn't notice it) LGPL... So what? AFAICS we're complying with section 6 (a/d) of LPGL. Anyhow, do we need to mention iconv/libxml somewhere in the docs? Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Patch: Query favourites
Dave Page wrote: Patch applied with the following changes: - Moved all deps to $PGASRC/../pgadmin3-deps/ on Windows. - Replaced the wxTreeCtrl with a ctlTree (which draws lines properly on GTK), and added the appropriate XRC resource handlers. There is a slightly odd effect with the text box on dlgAddFavourite and the wxTextEntry dialogue on Windows in which the cursor keeps returning to immediately before char 4 (even if the textbox is actually empty), but it does actually work as expected. Andreas; can you look at that please? I'm somewhat baffled... I'm currently rebuilding my win32 workstation, using VC2005, and struggling to find windows.h... I can see the issue with the latest snapshots I compiled, I'd guess some flags of that textbox are strange. A word about gtk build: After installing libxml-dev on my debian box, I had to add a link to /usr/include/libxml2/libxml as /usr/include/libxml. I wonder if this is expected. In addition, I needed to add -lxml2 in src/Makefile. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Query favourite comment
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 13 February 2006 14:18 To: Dave Page Cc: Magnus Hagander; pgadmin-hackers Subject: Re: [pgadmin-hackers] Query favourite comment So what? AFAICS we're complying with section 6 (a/d) of LPGL. Eh? Now we don't. Either of those would require that we supply the libiconv source code. 6b is the easiest one, but that requires that we dynamically link. Anyhow, do we need to mention iconv/libxml somewhere in the docs? Libxml is MIT licenced which is more or less the same as BSD from what I can see. And probably yes for iconv. I need to go through all of the PostgreSQL and pgAdmin installers and make sure we've not missed anything... Fine. We know you like this licensing stuff :-) 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] Patch: Query favourites
Magnus Hagander wrote: On a related note, this introduces dependencies on libxml2 and iconv. These are both available from www.xmlsoft.org, precompiled for Windows, and are both on most unixes already, however, on Windows there is no standard place for them to live. There are two sensible options I can see for these, and wxWidgets: C:\wxWidgets-2.6\ C:\libxml2\ C:\iconv\ Or C:\pgadmin-prereqs (or some other name) \wxWidgets-2.6\ \libxml2\ \iconv\ Thoughts/preferences? Wish we had easy soft links under win32... I like the latter. Even better if it could be made a relative directory wrt to the pgadmin directory. Say I have c:\src, then I could have c:\src\pgadmin3 and c:\src\pgamdin-preqreqs. Or so. +1. Relative path should consider the multi-version situation (1.4 and HEAD). So the path should be something like ../pga-prereq. I wonder if VCxx will work correctly with that. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Improved copying from Edit Data Grid - rough
Dave Page wrote: If you'd like to look at adding similar functionality to the query tool, that'd be great :-) Please note that the query tool output needs major redesign to use a virtual control; the current (wx) implementation is dead slow on some platforms. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] GrantWizard Property Crack?
Hiroshi Saito wrote: Hi Andreas. I am looking at the strange thing.? see, http://cre-ent.skcapi.co.jp/~saito/pgadmin3/pgAdmin3_GrantWizard_Crack.PNG Do you understand this somehow? Don't have a clue where this comes from: the notebook pages has only the checklistbox and two buttons. Could you use Spy++ to find out the window type/hierarchy? Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Patch: Query favourites
Dave Page wrote: -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: 30 January 2006 20:22 To: Dave Page; Andreas Pflug Cc: pgadmin-hackers@postgresql.org Subject: RE: [pgadmin-hackers] Patch: Query favourites As for the libxml2/msxml - I think going with *just* libxml2 is the way to go. The APIs are so completely different that it would be two completely different implementations. And AFAIK, there are no problems with libxml on Win32 in general. OK, I'll give it a go if I get 5 minutes. So yeah, that can definitly be done without an unreasonable amount of work. If that means that the feature will live, I'm fine with looking at that. But I'd like to know that first. (Implementation details aside of course, there can still be more of those to fix - the feature in principle, and the general idea of storing the data in a file in the users homedir etc) I like the idea, and agree with storing the data in the user's home directory. The data is definitely going to be too large to store sensibly in the registry or an ini file, and storing in the master database restricts you to a single server which, like you, would not help me much. I didn't think of one repository per server, but a dedicated repository server. This would allow roaming regardless of operating systems. Regards, Andresa ---(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] Patch: Query favourites
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 31 January 2006 12:19 To: Dave Page Cc: Magnus Hagander; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Patch: Query favourites I didn't think of one repository per server, but a dedicated repository server. This would allow roaming regardless of operating systems. That's not a bad idea, but it does introduce a whole new level of setup/configuration for the user - perhaps something to consider more fully along with the pgAgent setup. Hm, don't see the connection to pgAgent. What I was thinking of is an option repository server/db. E.g. when creating a new connection, instead of entering data manually info can be retrieved from repository. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Patch: Query favourites
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 31 January 2006 16:27 To: Dave Page Cc: Magnus Hagander; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Patch: Query favourites Hm, don't see the connection to pgAgent. What I was thinking of is an option repository server/db. E.g. when creating a new connection, instead of entering data manually info can be retrieved from repository. If we are going to have central repository of some description, then perhaps we should have a wizard to create it for the user. That Wizard could be used to setup the favourites repository, the connection repository, the pgAgent schema and so on, each of which could be setup on one or more servers as required by the user and appropriate for the type of repository (or whatever). Agred. There's no reason why we can create a Slony cluster from pgAdmin, but not the pgAgent schema (or a future repository schema). Regards, Andreas ---(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. I eyeballed the multibyte handling, it looks ok to me. But I found some nasty misbehaviours: select * from pg_cTAB - 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 Enter 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
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_cCtrl-Spc) _does_ popup the window. However, the popup 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_attCtrl-Spc won't do anything. - SELECT * FROM pg_class, pg_attribute WHERE Ctrl-Spc will deliver pg_attribute columns only. - SELECT * FROM pg_class JOIN pg_attribute ON Ctrl-Spc 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] Patch: Query favourites
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 29 January 2006 20:56 To: Andreas Pflug Cc: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Patch: Query favourites On this we clearly disagree (on the value of the feature, that is). But that's your choice, of course. I'll keep running with it myself until such a time as an alternative exists. Let's, as they say, agree to disagree on it. FWIW, I do think this would be a nice feature, and would tie in nicely with an idea I've been mulling over of having a centralised library site for SQL snippets. As we now have a postgres database, this should be the central repository for stuff like this. No need for XML here... Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Patch: Query favourites
Magnus Hagander wrote: This patch adds a favourites menu to the query tool, where one can store often-used queries. It brings along build dependencies on wxxml2 (http://wxcode.sourceforge.net/components/wxxml2/) and libxml2 (which comes from the first). The tradeoff between additional benefit (you can already store often-used queries in standard files) and increased wx dependencies (actually not wx but wxcode, which can make it a nightmare dealing with distributions) makes this patch really expensive. IMNSHO, too expensive. 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] Patch: Query favourites
Magnus Hagander wrote: Anyway, it could be rewritten to either not use XML at all, or to not use wxxml (say by linking directly to libxml, which is likely to be on the system already considering how many packages use it). It just makes it easier when you don't have to maintain the code youself. There must be some XML stuff in std wx, since XRC uses XML, dunno how reusable that is. As for the fact that you can already store them in standard files - sure you can. It's a matter of convenience. Still appears as a duplication of features. What's wrong with recent files? Actually, I'd like it better to have a means of adding macros/scripts or so to pgAdmin, i.e. wxPython. This would enable pgAdmin extensions, keeping the pgAdmin core relatively pure. 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] Patch: Query favourites
Magnus Hagander wrote: Anyway, it could be rewritten to either not use XML at all, or to not use wxxml (say by linking directly to libxml, which is likely to be on the system already considering how many packages use it). It just makes it easier when you don't have to maintain the code youself. There must be some XML stuff in std wx, since XRC uses XML, dunno how reusable that is. It specifically says that the API is not stable and should not be used. (http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/xml/xml.h?rev =1.5content-type=text/vnd.viewcvs-markup and friends) As for the fact that you can already store them in standard files - sure you can. It's a matter of convenience. Still appears as a duplication of features. What's wrong with recent files? No hierarchy, very very limited number of entries, no control over which entries go on the list (say when you open a one-time file to run, it will still steal a position on the list), no ability to add descriptive entries. I'm sure there are more, but that's what I came up with whlie typing without needing to think about it. Actually, I'd like it better to have a means of adding macros/scripts or so to pgAdmin, i.e. wxPython. This would enable pgAdmin extensions, keeping the pgAdmin core relatively pure. Sure, that'd be nice. Still, that adds a dependency on *python*, which is *huge* compared to wxxml... I don't mind adding dependencies if benefits are huge (last addition was OGL for graphical explain, which is a std wx contrib module). The few preferred queries I'm using are in some files, and I simply mark and execute them. That's why I can't see any benefit from such a favourite feature. And I don't see the point in this case. The point is, the scripting option I'm thinking of would allow you to declare your own menu entry for your preferred query (which might consist of a dialogue, formatting your result) so it's not the query you're storing, but but the feature/task/whatever. Just as we have a status display, not just a favourite select * from pg_status. Regards, Andreas ---(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] SVN Commit by dpage: r4965 - trunk/pgadmin3
[EMAIL PROTECTED] wrote: Author: dpage Date: 2006-01-25 10:31:01 + (Wed, 25 Jan 2006) New Revision: 4965 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=4965view=rev Log: Testing post-commit email script... Adding frmPgpassConfig.* would be a great idea too... 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] SVN Commit by dpage: r4965 - trunk/pgadmin3
Dave Page wrote: Adding frmPgpassConfig.* would be a great idea too... Yeah, yeah, picky, picky ! As usual :-) To continue: The pgpass dialog captions could need some review... 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] pgAdmin website translations
Dave Page wrote: When you have finished, please do not forget to set your name and email address in the translation header, then forward me the .po and .mo files to be added to the site. Translation template: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/www/locale/p gadmin3_website.pot How 2 switch the site language? Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
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] bugfix: Encoding of config files
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 23 January 2006 23:31 To: Dave Page Cc: Magnus Hagander; pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] bugfix: Encoding of config files NB, when reading AND writing! And the wxUtfFile class will behave differently when creating a file or rewriting (will preserve encoding in the latter case) Err, ok. Well, how does the attached look o'Guru of encoding and such things? No need to detect encoding, file reading/writing committed. This problem probably persisted before, but problematically the problem that when opening a file after a file was opened (just open a file, and then open a recent file) is still persistent as problem. Probably a not-so-clean destructor (line array?) 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] bugfix: Encoding of config files
Dave Page wrote: Thanks, patch applied to 1.4.x and 1.6. Hm, this certainly should be consistent, but I'd guess most files will use a 1-byte system charset, not UTF8, thus wxConvLibc not wxConvUTF8 is the right one. 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] Patch: Config editors
Magnus Hagander wrote: Attached patch implements an editor for pgpass.conf/.pgpass modeled on the HBA editor. In doing so it also: Do we need this? .pgpass is maintained automatically from pgAdmin. No it's not :-) Not if you want to use wildcards, for example. Or did I miss some way of doing that? Ok. Hope users don't get confused that pgAdmin uses two ways to (partially :-) maintain the file. * Adds the ability to delete a row to the pg_hba editor Hm, missed that? Probably thought disabling (commenting out) is enough. Then you can never get rid of the line at all, can you? That sounds like a bad idea to me... And there is a different way to comment it out already, so if that's all you need then this patch isn't needed. I think a real delete is a good thing, though. Ok. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] bugfix: Encoding of config files
Magnus Hagander wrote: Thanks, patch applied to 1.4.x and 1.6. Hm, this certainly should be consistent, but I'd guess most files will use a 1-byte system charset, not UTF8, thus wxConvLibc not wxConvUTF8 is the right one. I for one certainly bow to that one. As said before, the encodings dealings is defintily not my strong side :-) Well, itsapita. Nobody likes to deal with it voluntarily... :-) Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
