[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] Rev 4704
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 09 November 2005 12:50 To: Dave Page Cc: pgadmin-hackers Subject: Re: Rev 4704 Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 09 November 2005 10:20 To: Dave Page; pgadmin-hackers Subject: Rev 4704 Dave, I'm trying to make sense of your change of ShowTipOfTheDay's type from bool to int for 1.5. The type was changed to bool in 1.3, and I don't see a reason to change it again. As we discussed last week, it causes an assert in debug builds on Windows as wx seems to be unable to cast from DWORD to bool. Even deleting the registry key and allowing it to recreate it itself doesn't help. I remember seeing the msg now, but I don't see why we should care about an assert in debug builds. Just ignore it, and touch the TOTD flag. That's the problem - touching the flag made no difference whatsoever, and having it stop on assert every time I try to debug is really annoying. I'm sure it *does* work. Show TOTD, and acknowledge not to show it again. We had this from 1.2 to 1.4, we don't need this again for 1.4->1.6 I'm seeing an unconditional error msgbox right now, which is even more painful (and probably not restricted to debug build) From what? I don't see any errors here anymore on Windows, and there's nothing new appeared on Linux. The registry key type and on/off values haven't changed either It changed from string to dword! 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] Rev 4704
Dave Page wrote: OK, I fixed this, checking for DWORD->STR change on MSW now, backpatched for 1.4.1. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-hackers] automake
How to handle the [tar-ustar] option in configure.ac? I had to remove it in my setup. 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] Be careful in postgresql.conf of 8.1.
Hiroshi Saito wrote: Hi Andreas. Although this is a comment, it is bad condition. postgresql.conf #data_directory = 'ConfigDir' # use data in another directory #hba_file = 'ConfigDir/pg_hba.conf' # host-based authentication file #ident_file = 'ConfigDir/pg_ident.conf # IDENT configuration file Ummm, This should be as follows. #ident_file = 'ConfigDir/pg_ident.conf' # IDENT configuration file It is conf-editor gets confused. What do you consider? pgsql needs fix. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] automake
Dave Page wrote: On 9/11/05 8:22 pm, "Andreas Pflug" <[EMAIL PROTECTED]> wrote: How to handle the [tar-ustar] option in configure.ac? I had to remove it in my setup. You probably need to upgrade to automake 1.9.6. When I was packaging 1.4 the other night, I suddenly realised that whoever added the slony docs ( :-p ), forgot to add them to makefile.am, so they weren't included in the tarball. Having added them to the makefile, I rebuilt the tarball only to get errors from tar about three of the slony docs having too-long filenames, and find that the tarball itself way 12MB instead of the normal 6!! The tar-ustar option makes tar work in a mode in which 255 character names are supported instead of the default 99. A one off upgrade to automake on the /older/ developer systems seemed far less pain than manually renaming the slony docs forever more. Did that, automake works now, but Makefile will have a missing separator in line 377. automake-1.9 will claim that *.m4 is created by aclocal-1.4, but aclocal-1.9 will have throw warnings and automake-1.9 will fail then. If 1.9 is needed, it should be called explicitely in bootstrap, no? Current status: can't build on linux. automake/aclocal are 1.9.6 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] Search/replace
Dave Page wrote: Problem is that in both cases I get a crash in wx code, when none of our functions are on the call stack, after the new dialogue has been created. If running in the VC++ debugger, it breaks telling me I've hit a user breakpoint inside wx's assert handling code (where there definitely aren't any breakpoints that I've inserted). It won't let me break properly from the assert dialogue. After lengthy investigation the answer is quite simple: wx is broken. The dialogs sample has the same problem. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] automake
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 10 November 2005 09:39 To: Dave Page Cc: pgadmin-hackers Subject: Re: automake Did that, automake works now, but Makefile will have a missing separator in line 377. automake-1.9 will claim that *.m4 is created by aclocal-1.4, but aclocal-1.9 will have throw warnings and automake-1.9 will fail then. If 1.9 is needed, it should be called explicitely in bootstrap, no? Eh? Do you have both installed in different locations or something? No, /usr/bin. All versions are present, but ./bootstrap relies on aclocal/autoconf to point to the right versions. currently, aclocal-1.4 will run (without problem), but automake-1.9 will claim aclocal version and configure isn't created. aclocal-1.9 won't run, many errors. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Possible bug renaming roles
Antonio wrote: Dear Sirs: I looked in the pgAdmin web page for a place to report bugs, but I couldn't find it. So I send it to this list. If I'm wrong, please let me know. Bug description: - When you try to rename a role, you get an error. Fixed in svn for 1.4.1 and HEAD, thanks for reporting. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Search/replace
Dave Page wrote: Oh, good to know it's not me for once!! Thanks for looking. It did strike me that the replace dialogue can do find as well - perhaps we should just remove the find one altogether? This is uncommon, we should provide separate dialogs. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] automake
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 10 November 2005 11:04 To: Dave Page Cc: pgadmin-hackers Subject: Re: automake Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 10 November 2005 09:39 To: Dave Page Cc: pgadmin-hackers Subject: Re: automake Did that, automake works now, but Makefile will have a missing separator in line 377. automake-1.9 will claim that *.m4 is created by aclocal-1.4, but aclocal-1.9 will have throw warnings and automake-1.9 will fail then. If 1.9 is needed, it should be called explicitely in bootstrap, no? Eh? Do you have both installed in different locations or something? No, /usr/bin. All versions are present, but ./bootstrap relies on aclocal/autoconf to point to the right versions. currently, aclocal-1.4 will run (without problem), but automake-1.9 will claim aclocal version and configure isn't created. aclocal-1.9 won't run, many errors. Is this OK now (following an svn update)? I get quite some warnings from aclocal, but after rm -r config* ac*;svn update I'm workable again. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Hide databases
First of all, stay on the lists! Since this is new stuff, it should go to -hackers. Uwe Dalluege wrote: do you realised it (hide databases) in 1.5.0 Nov 9 2005 win32-version ? I have installed it but I could not see new behaviour. All databases and schematas are shown. See properties of db or schema to enter the restriction. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Hide databases
Andreas Pflug wrote: First of all, stay on the lists! Since this is new stuff, it should go to -hackers. Uwe Dalluege wrote: do you realised it (hide databases) in 1.5.0 Nov 9 2005 win32-version ? I have installed it but I could not see new behaviour. All databases and schematas are shown. See properties of db or schema to enter the restriction. Correction: property of server to enter db restriction, property of db to enter schema restriction. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Hide databases
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug Sent: 11 November 2005 11:19 Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] Hide databases Andreas Pflug wrote: First of all, stay on the lists! Since this is new stuff, it should go to -hackers. Uwe Dalluege wrote: do you realised it (hide databases) in 1.5.0 Nov 9 2005 win32-version ? I have installed it but I could not see new behaviour. All databases and schematas are shown. See properties of db or schema to enter the restriction. Correction: property of server to enter db restriction, property of db to enter schema restriction. Out of interest, what's the format of the restriction string? Delimited list, SQL restriction, regexp? something like datname=user (validity is checked) Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-hackers] Registry
going to -hackers The registry format changed a day ago; the old was getting too crowded. 1.5 will convert from older versions. Oh, is that what deleted all my servers? Took me ages to put them back again :-( Um yes, old registry entries are deleted after creation in the new location to avoid that new entries are overwritten by old ones. Whatever killed mine off didn't delete them, it just set all the settings to empty strings so I had lots of servers like: (:0) as Miha did :-( 1.5 *does* delete the values, but wx will read a non-existent value as empty and recreate it. What's also odd, is that looking in the registry, I still seem to be using the old format having re-added my servers. Obviously I haven't picked up the change yet, which makes me wonder what blew all the entries away. /D PS. Just rebuilt - settings upgraded fine. Now how do I test fixes in 1.4.x without getting in a mess I wonder... Any suggestions? We could copy them over, if newer don't exist, and leave the old ones. But this would leave quite some (pre-1.5) garbage. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Registry
Dave Page wrote: 1.5 *does* delete the values, but wx will read a non-existent value as empty and recreate it. Because the count value still read 12 or whatever I guess. Yup. Do we still need the count in the new scheme? Can't we just iterate through all the subkeys? We'd have to delete entries if servers are removed from the tree. I can remember incidents where count was corrupted (for whatever reason) and no servers where displayed, but the registry was still there so it was sufficient to increase the count. Any suggestions? We could copy them over, if newer don't exist, and leave the old ones. But this would leave quite some (pre-1.5) garbage. I'm not convinced it was actually worth the change - it's not like it was something that the user needed to hack normally, or would cause performance issues. If you add a schema restriction you'll understand why I did this. Alternatively, we could try to convince Tom to extend pg_database and pg_schema :-) 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] Registry
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 11 November 2005 16:51 To: Dave Page Cc: Miha Radej; pgadmin-hackers@postgresql.org Subject: Re: Registry I'm not convinced it was actually worth the change - it's not like it was something that the user needed to hack normally, or would cause performance issues. If you add a schema restriction you'll understand why I did this. Ahh, yes, I see! Alternatively, we could try to convince Tom to extend pg_database and pg_schema :-) Err, yuh. You go ahead... No, *you* wear the project leader hat, your turn :-> Ok, thou it was undoubltly a really brilliant idea of mine to delete pre-1.5 entries, it might be a good idea to keep them for now, just to please you :-) Regards, Andreas :-) /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] multiple site/db central backup with pitr using
OpenMacNews wrote: hi all. just coming up to speed on the idea-basics, but thought i'd ask (*while* i rtfm ...) if "it" can be done in/with pgadmin3. i've numerous boxes with pgsql instances, and the usual assortment of DBs/box. backing up, til now, has been script-driven, each box being backed up separately ... but, now, getting to be tedious/messy. i'd like to back up to a central server, with version control. from irc chat, sounds like the right way to do this is connect from local to remote, pg_dump remote db to local disk over network, and implement "point in time recovery" (cref: http://www.postgresql.org/docs/current/static/backup-online.html). in principle, all doable via shell script ... doable/automated via pgadmin3? PITR and pg_dump are two different concepts, both allowing online backup. You could run the backup processes using the pgAgent scheduler, which would provide handling integrated in other db related tasks, i.e. in pgAdmin. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] SVN Commit by dpage: r4744 - in trunk/pgadmin3/src:
[EMAIL PROTECTED] wrote: Author: dpage Date: 2005-11-16 21:57:28 + (Wed, 16 Nov 2005) New Revision: 4744 Modified: trunk/pgadmin3/src/ctl/ctlSQLBox.cpp trunk/pgadmin3/src/include/ctl/ctlSQLBox.h Log: Swap between Find/Replace dialogues correctly on non-windows platforms properly. Looks like we might have to live with slightly odd behaviour on Windows due to the design of wx :-( Hu, slightly odd? Isn't this crashing for you? It did for me, since apparently there are messages stuck in the msg queue that aren't removable even by Yield. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] SVN Commit by dpage: r4744 - in trunk/pgadmin3/src:
Dave Page wrote: On 16/11/05 10:13 pm, "Andreas Pflug" <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: Author: dpage Date: 2005-11-16 21:57:28 + (Wed, 16 Nov 2005) New Revision: 4744 Modified: trunk/pgadmin3/src/ctl/ctlSQLBox.cpp trunk/pgadmin3/src/include/ctl/ctlSQLBox.h Log: Swap between Find/Replace dialogues correctly on non-windows platforms properly. Looks like we might have to live with slightly odd behaviour on Windows due to the design of wx :-( Hu, slightly odd? Isn't this crashing for you? It did for me, since apparently there are messages stuck in the msg queue that aren't removable even by Yield. It shouldn't crash on Windows (can't test ATM) because the changes are all #ifndef __WXMSW__. 'k, missed that. 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] french po updates and ui patch
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume LELARGE Sent: 21 November 2005 17:37 To: pgadmin-hackers Subject: [pgadmin-hackers] french po updates and ui patch Hi all, Hi, You'll find attached an update for the french .po file. Please send the complete updated .po and .mo file. Although there shouldn't be any issues with French, as a general rule I try to avoid patching the po files as they can be easily broken in ways that I might not spot. Please apply it in the REL-1_4_0_PATCHES branch. Thanks. We keep all translations in sync, so I'll add the updated po/mo file to trunk as well. The second one aims to better use checkbox. You used a label and a checkbox instead of a checkbox with its own label. I modify this. I think it makes a better UI. You can click on the text instead of the box. Hope you'll find this interesting and that you'll apply it. Iirc, there was a reason why they're separate (I just can't think what it was) - can you remember Andreas? Yup; we mostly have the text on the left side. Only win32 has such a flag, other systems know text on the right side only. There might be areas where we really can change the checkboxes, I'll have a look at Guillaumes patch some day. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] french po updates and ui patch
Andreas Pflug wrote: The second one aims to better use checkbox. You used a label and a checkbox instead of a checkbox with its own label. I modify this. I think it makes a better UI. You can click on the text instead of the box. Hope you'll find this interesting and that you'll apply it. Iirc, there was a reason why they're separate (I just can't think what it was) - can you remember Andreas? Yup; we mostly have the text on the left side. Only win32 has such a flag, other systems know text on the right side only. There might be areas where we really can change the checkboxes, I'll have a look at Guillaumes patch some day. I rewieved the issue now. In wx2.6, the text-on-left-side-only restriction is gone, but this won't help us too much: What we need is left-aligned text, and right-aligned checkbox to position all descriptive text and all controls aligned; a checkbox won't allow this. Guillaumes patch will simply add all descriptive text for checkboxes to the right of the box itself, this looks really ugly for most dialogs (we have this on the options dialog, but this is different because we don't need to give a consistent look&feel as in the case of pgsql objects dialogs, so we could order the controls to look nicely). 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] Server status query problem
Dave Page wrote: Hi Andreas, It was pointed out to me that the server status lock tab doesn't show data correctly - specifically, the username is always blank, and the query string normally shows up as . It seems the cause is that most of the stats functions don't take a PID as an argument, but a backend ID between 1 and the current number of backends. A hacked together replacement query looks like the following, but before I appy it I just wanted to run it past you and the list in case I missed anything: Arg Testing for HOURS, coding it but you already committed it... Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] FW: Explain graphical explain...
Dave Page wrote: Hi Andreas, Niko forwarded these to me. They look great to me (but then I have the artistic imagination of a squirrel!) - what do you think? Source is modified, preliminary graphics added. Should we backport this to 1.4? Just a matter of copy/paste. 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] pgadmin 1.4.1?
Should we have a 1.4.1 release as soon as pgsql 8.1.1 is out? 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 1.4.1?
Dave Page wrote: Before would be good, for the installer! Agreed, but we should fix the grant combobox issue first. Maybe tomorrow. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgadmin 1.4.1?
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 30 November 2005 22:52 To: Dave Page Cc: pgadmin-hackers@postgresql.org Subject: Re: pgadmin 1.4.1? Dave Page wrote: Before would be good, for the installer! Agreed, but we should fix the grant combobox issue first. Maybe tomorrow. Yeah, I was hoping to look at it some more. Ok, found that beast. wx changed the wxChoice/wxComboBox API, introducing a new method GetCurrentSelection that has the functionality of <2.6.2 GetSelection. Fool me, believing that 2.6.x had a stable API on basic controls, so it wouldn't matter if 2.6.0 or 2.6.2 is used... Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] SVN Commit by andreas: r4773 - branches/REL-1_4_0_PATCHES/pgadmin3/src/ctl
Dave Page wrote: Hi Andreas, I already tried this fix - it makes no difference :-( I just crosschecked, it _does_ work for me. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-hackers] 1.4.1 Release
Dave, currently we can't freeze 1.4.1, the 2.6.2 API fuckup has impact throughout the app. In addition, a short fix won't work because apparently I'm experiencing a compiler error (base method called thou overloaded method exists). Stay tuned. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] 1.4.1 Release
Dave Page wrote: Hmm, good job I had to postpone the wrap till Monday then :-) Not in the mood for smileys for several reasons; my recent remarkes were censored. Thankfully, the guys who decided this major change in a dot-release are far away... Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] 1.4.1 Release
Dave Page wrote: I'd definitely complain - might make them think twice next time. Didn't realise it was quite this bad :-( Me neither, until I found editing a pg_hba.conf .line behaving weird on linux when changing the type and began to dig further. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] 1.4.1 Release
Andreas Pflug wrote: Dave Page wrote: I'd definitely complain - might make them think twice next time. Didn't realise it was quite this bad :-( Me neither, until I found editing a pg_hba.conf .line behaving weird on linux when changing the type and began to dig further. 'k, this wasn't exactly fun... Hopefully 1.4.1 and 1.5 working for 2.6.0-2.6.2 on win32 and gtk2 now. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] [GENERAL] Missing variable "role" in "pg_settings"?
Florian G. Pflug wrote: Hm, but before 8.1 there was no "alter user set ", was there? A look at http://www.postgresql.org/docs/7.3/static/sql-alteruser.html proves you wrong. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] New Brazilian Translator/Maintaner.
Marcos Alves T. de Azevedo wrote: New Brazilian Translator/Maintaner. My name is Marcos Alves T. de Azevedo (Marcos Azevedo) and I would like to be the translator for Brazilian (PT_BR) language. Fine, Brazilian pgAdmin users will probably be very thankful! Translator's page changed, will take a while to show up on the website. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pg_autovacuum vs autovacuum
Peter Eisentraut wrote: The autovacuum feature in PostgreSQL 8.1 is called "autovacuum", not "pg_autovacuum", as pgAdmin makes one believe. To make the terminology consistent, I propose the following small patch. Yup, applied (and corrected in all applicable translations as well) 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] Fixed German tips
Peter Eisentraut wrote: Here is an update of the German tips file which brings the text closer to actual German. :-) Well, somebody already called my translations "slightly broken German". No big career as translator waiting for me... Interestingly, nobody ever nagged about my broken English texts. Probably too broken to even think about fixing them... Or never recognized as wannabe-English. fix them... Thanks for review, applied. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Schema bug
Guillaume LELARGE wrote: Hi, I found a weird bug today. If you rename the public schema, it becomes unavailable. Here is a patch to fix it. It modifies the query to use the oid instead of the schema's name. Works great on Linux, should'nt be a problem on win32. Actually, to me renaming the public schema appears as the primary bug... There are many ways to corrupt pgAdmin's behaviour, and you found one of 'em. Renaming public is so irregular, I doubt it's worth changing the behaviour. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Schema bug
Florian G. Pflug wrote: Andreas Pflug wrote: Guillaume LELARGE wrote: Hi, I found a weird bug today. If you rename the public schema, it becomes unavailable. Here is a patch to fix it. It modifies the query to use the oid instead of the schema's name. Works great on Linux, should'nt be a problem on win32. Actually, to me renaming the public schema appears as the primary bug... There are many ways to corrupt pgAdmin's behaviour, and you found one of 'em. Renaming public is so irregular, I doubt it's worth changing the behaviour. This argument scares me... I believe a GUI-Tool shouldn't impose any additional restrictions to what you can do with your database - otherwise GUI-Users become second-class citzicens when compared to those who use the commandline/psql. Why exactly does pgadmin depend on the existance of the public schema? It does *not* depend on its existence. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] SVN Commit by dpage: r4809 - branches/REL-1_4_0_PATCHES/pgadmin3/i18n/fr_FR
Dave Page wrote: Hmm, this is a particularly sneaky bit of coding on Andreas' part, and if I'm reading it correctly, then no, it doesn't matter. The user will never see it anyway - it's just used to identify localised error messages from the server. Right, looking so funny because there's no locale independent return code for these libpq messages, which is a PITA. I should be looking into this for pgsql 8.2. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Ready for 1.4.1?
Dave Page wrote: I expect to package pgAdmin 1.4.1 tomorrow to bundle with PostgreSQL 8.1.1. If there are any last minute fixes, let's be 'aving them today please!! No problem with me. I still can't make sense of the "passwords not stored" issue on win32. There's now debugging code to check for the proper file location, maybe that helps. 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] i18n files
Hi Dave, I did quite some updates on *.mo and *.po files lately, but only for HEAD. IMHO there's no point in maintaining head and trunk for these files, since they're 100 % backward compatible. (and CHANGELOG.txt covers all changes too). Just a note before 1.4.1 is packaged with outdated versions :-) Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] i18n files
Dave Page wrote: Hi Andreas, 1.4.1 will be packaged with whatever is in the 1.4 branch. Aside from the fact that I have enough to do at release anyway (doc updates, 4 builds of pgAdmin, refreshes of everything else in pgInstaller, and it's build and testing) without having to merge translations from trunk, the tags/branches in SVN should match exactly what is released to allow any build to be easily recreated. Plus of course, there are makefiles and build scripts to keep in sync. Ok, will update releasable languages. Unfortunately, still no nordic knight in a shiny armour showed up to lift our Swedish translation from 1.0 to 1.4... :-) Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] i18n files
Dave Page wrote: Thanks. What's the knight about btw? Some bizarre fantasy of yours? :-p No, just waiting for a hero :-) 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] Schema bug
Dave Page wrote: I still think this patch should be applied. Does anyone see a reason /not/ to do this? Hm, Guillaume started a thread on pgsql-hackers about renaming system schemas in general, maybe we should wait for the result of that discussion. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] SVN Commit by andreas: r4836 - in branches/REL-1_4_0_PATCHES/pgadmin3/src:
[EMAIL PROTECTED] wrote: Author: andreas Date: 2005-12-11 22:16:17 + (Sun, 11 Dec 2005) New Revision: 4836 Modified: branches/REL-1_4_0_PATCHES/pgadmin3/src/include/ctl/ctlComboBox.h Log: Another wxComboBox(2.6.2) related fix Well Overloading GetSelection() corrupted some internal wxComboBox handling, I noticed it in frmQuery database selection. There might be more places affected. :-( Regrets, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] Schema bug
Florian G. Pflug wrote: I'd prefer system-catalogs being excluded by name - preferably the exclusion-list would be editable, and part of the pgadmin preferences. Seems more transparent to me - and future-proof, in the sense that even if a future postgres version chooses to rename some catalog, the user will be able to just add the new names to the exclusion list. There's already a database restriction and a schema restriction, just use it. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Schema bug
Jim C. Nasby wrote: On Tue, Dec 13, 2005 at 12:48:55AM +0100, Guillaume LELARGE wrote: Well, it seems that pg_* schemas are system schemas and that public and information_schema schemas are public one. I think we should exclude system schemas depending on their names and show public and information_schema, whatever their actual name are. BTW, it'd probably be useful to have an easy way to show everything. It's not that uncommon to want to go into the catalog tables... This option is called "system objects" and is present in pgadmin since the very beginning... 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] Schema bug
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume LELARGE Sent: 13 December 2005 23:44 To: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Schema bug Le Mardi 13 Décembre 2005 00:48, Guillaume LELARGE a écrit : Le Samedi 10 Décembre 2005 16:55, Andreas Pflug a écrit : Dave Page wrote: I still think this patch should be applied. Does anyone see a reason /not/ to do this? Hm, Guillaume started a thread on pgsql-hackers about renaming system schemas in general, maybe we should wait for the result of that discussion. Well, it seems that pg_* schemas are system schemas and that public and information_schema schemas are public one. I think we should exclude system schemas depending on their names and show public and information_schema, whatever their actual name are. I can bring a new patch if you agree with this and if you find this useful. What about this one ? I don't have a problem with that. Anyone else? I *do* have a problem if information_schema becomes non-system. For pgsql-core this is non-system, but a user would consider this system and like to have its display suppressed for day-to-day work. I'm still not convinced we need to do anything. Renaming public is highly irregular, and finally showing system objects will make it reappear. The schema restriction allows individual filters who likes it. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Schema bug
Dave Page wrote: I'm still not convinced we need to do anything. Renaming public is highly irregular, and finally showing system objects will make it reappear. The schema restriction allows individual filters who likes it. Renaming public is irregular, but if we can allow it without breaking anything else, then I see no reason why we shouldn't do it. So for god's sake do implement it, but in general I'm less than inclined to implement workarounds for people doing weird things to the db. I'm waiting for the guy who claims that his "was-public" schema suddenly reapperars in pgadmin, while he just renamed it to have it hidden from the users There *are* admins that deliberately rename pg objects to hide them from pgadmin's sight. 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] 141 segfaults on language change
Devrim GUNDUZ wrote: Hi Dave, On Wed, 14 Dec 2005, Dave Page wrote: I installed my 1.4.1 RPM . When I want to change language from English to Turkish, pgadmin3 halts with a segfault. Do you need additional info for that? strace output fox example? Immediately on language change, or shortly afterwards? Translations usually cause crashes if there's a string with the wrong number of parameters in it and pgAdmin tries to use it. Immediately on language change. And yes, a backtrace would be good thanks! Ok, I'll send a strace shortly. I don't have it on my Debian; the Turkish locale file looks ok. 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] Client-side password encryption
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Peter Eisentraut Sent: Sun 12/18/2005 2:25 AM To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] Client-side password encryption Commands like CREATE USER foo PASSWORD 'bar' transmit the password in cleartext and possibly save the password in various client or server log files. I have just fixed this for psql and createuser to encrypt the password on the client side. A quick check of the pgadmin3 source code shows that you are also affected by this issue. I ask you to check where you paste cleartext passwords into SQL commands and change those to encrypt the password before sending or storing it anywhere. The required function pg_md5_encrypt() is contained in libpq. So did you just rip it from there into psql? I don't see it in the list of libpq exports so if thats not the case, on Windows at least we'll need to change the api, and possibly the dll name as well to avoid any compatibility issues. And a prototype in libpq-fe.h wouldn't hurt either... And a macro, to enable distinguishing md5-enabled libpq versions from older versions. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] dlgDatabase_patch
Hiroshi Saito wrote: Hi Andreas. It is one more addition.:-) Comment cannot be attached to a database. Applied, thx. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] dlgLanguage_patch
Hiroshi Saito wrote: Hi Andreas. Language Property change method is problem. This is name and comment fixed. Partially applied, there was more flakey code around cbName/txtName. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] 1.4.1 On OSX
Dave Page wrote: Hi Andreas, I finally tracked down the bug in 1.4.1 on Mac which causes a crash whenever pretty much any property dialogue is opened. Basically, in ctlComboBox::GetSelection() we call GetCurrentSelection(). In wxMac however, this simply calls GetSelection() which is a virtual and results in our GetSelection() actually getting called, in turn causing a loop and eventual stack overflow. So, the attached patch seems to fix the problem and return the auto-complete code to the same slightly-broken-but-usable state that it was in 1.4.0 (i.e, you can only type the first character of a data type for example, and the first match will be selected). Can you take a look and confirm my analysis (or call me an idiot, whatever is correct!) before I apply this to both branches and packare 1.4.1.plus please? In general I agree. I committed a fix in ctlComboBoxFix doing essentially the same, but the version dependent GetCurrentSelection code isn't cluttered around the sources this way. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] 1.4.1 On OSX
Dave Page wrote: On 21/12/05 1:12 pm, "Andreas Pflug" <[EMAIL PROTECTED]> wrote: Dave Page wrote: Hi Andreas, I finally tracked down the bug in 1.4.1 on Mac which causes a crash whenever pretty much any property dialogue is opened. Basically, in ctlComboBox::GetSelection() we call GetCurrentSelection(). In wxMac however, this simply calls GetSelection() which is a virtual and results in our GetSelection() actually getting called, in turn causing a loop and eventual stack overflow. So, the attached patch seems to fix the problem and return the auto-complete code to the same slightly-broken-but-usable state that it was in 1.4.0 (i.e, you can only type the first character of a data type for example, and the first match will be selected). Can you take a look and confirm my analysis (or call me an idiot, whatever is correct!) before I apply this to both branches and packare 1.4.1.plus please? In general I agree. I committed a fix in ctlComboBoxFix doing essentially the same, but the version dependent GetCurrentSelection code isn't cluttered around the sources this way. Annoyingly that's one of the first fixes I tried and it didn't work. Well the wxComboBox code is a shy guy (remember how reluctant it's mentioned in 2.6.2 release notes). Maybe you pressed a keyboard button too harsh, and it was frightened :-) 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] Please drop the dangerous libssl and libcrypto deps
Raphaël Enrici wrote: Dear friends, Loic Minier(CCed) provided a patch to prevent pgadmin3 1.2.2 from being linked to a different libssl version than libpq when dynamically built with an already ssl enabled libpq. The full bug report and original patch by Loic can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341117 Attached is an svn diff for 1.4.1 release that I'm using for the package I'm about to upload to Debian (patch_libpqssl_1.4.1). You'll also find a fully untested patch for trunk (patch_libpqssl_current). Please recheck and apply if eveything's ok with them. Cheers, Raph Index: acinclude.m4 === --- acinclude.m4(revision 4858) +++ acinclude.m4(working copy) @@ -227,7 +227,10 @@ else if test "$pgsql_ssl_libpq" = "yes" then -LIBS="$LIBS -lssl -lcrypto -lpq" + # no idea why -lssl and -lcrypto were included here, as this +# support is provided via libpq +#LIBS="$LIBS -lssl -lcrypto -lpq +LIBS="$LIBS -lpq" else LIBS="$LIBS -lcrypto -lpq" fi We probably need this with static linking? 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: r4860 - trunk/pgadmin3/src/ui
[EMAIL PROTECTED] wrote: -store password +Store password Ugh! That also hits the translations... Regards, Andresas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Client-side password encryption
Peter Eisentraut wrote: The officially sanctioned function for this is now PQencryptPassword() in libpq. Please consider using it when available. Ok, we'll use it ASAP. But how to detect if it's available or not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. 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] Client-side password encryption
Magnus Hagander wrote: The officially sanctioned function for this is now PQencryptPassword() in libpq. Please consider using it when available. Ok, we'll use it ASAP. But how to detect if it's available or not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. You're going to have to detect this at runtime, aren't you? With that, GetProcAddress() on win32 and whatever it's called on *nix should be the way to go? We need this at compile time, to check if the prototype is present. If it is, the function should be present in the lib we're linking to as well. IFAIR there was consense some weeks ago that libpq should be versioned on win32 too, so a libpq dev environment should have a libpq.lib that references libpq-82.dll (or newer). On *ix, standard lib versioning will do the job. 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] Client-side password encryption
Peter Eisentraut wrote: Am Donnerstag, 5. Januar 2006 12:40 schrieb Andreas Pflug: Ok, we'll use it ASAP. But how to detect if it's available or not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. Just use AC_CHECK_FUNCS(PQencryptPassword) Um, no autoconf in our win32 environment... 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: commandline connect/launch
Magnus Hagander wrote:
Attached patch makes it possibe to specify a server description to
auto-connect to on the commandline ("-s mydbserver"), and also to have
pgAdmin automatically launch the query tool ("-s mydbserver -q"). It
will still open the main window as well, as there seems to be
interaction between the query window and the main one that I'm not fully
understanding yet :)
It also rearranges the commandline parsing to use the wx class for
commandline parsing. It just made things much easier to do it that way.
Hopefully I didn't break anything else :-) As a bonus, there is now a
"/h" for help on commandline args.
Ok, back from holidays, trying to catch up (with only few time to
spent). Fixed doc (-c takes directory) and help strings (translatable).
Regards,
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] pgAdminIII feature proposal - Logging the SQL
Tomek Kochanek wrote: It would very nice to have the option to log all changes in database. It will help me to manage changes on testing and production server. Currently it's possible to log all queries but it's not the good sollution, because you have to filter what are system queries and what isn't. This is already planned/partially implemented for quite a while. Stay tuned. Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Website
Dave Page wrote: Hi, An essentially complete new website is online at http://wwwdevel.pgadmin.org/. I've stuck with pretty much the current design, but with rewritten CSS and a new colour scheme to match the current pgAdmin splash screen. A really nice piece of work! Just a small issue: I noticed you changed docs to point to the new site. To keep older versions runnable, a redirecting link should be kept on the website. And where's the svn? Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 08 January 2006 15:05 To: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Query tool: Autocompletion Attached is a first attempt at autocompletion for the SQL Query tool. It probably needs some more work, but it's a start :-) It's based on the tab completion in psql. The idea is to pull the latest and greatest tab-complete.c from psql, then run it through a perlscript that picks out the tasty parts. Anyway. Attached is the patch. I've also included a tab-complete.inc from the current Due to a bug in the Visual C++ compiler, it *has* to be compiled as "C" not as "C++". Thus, a bit if ugly glue is required between those two worlds :-)psql - to make it build directly (without adding a build dependency on perl), this one is what should probably go in svn, and then be manually sycned onw and then from psql. "tabcomplete.c" needs to be added to the build project (I'm devving in Visual Studio 2003, so I can't modify the .dsw from there easily). I've only tested this on Windows so far. Wouldn't surprise me if some minor work is needed to build on *nix. I'm also unsure if I can get away with the easy way I pass strings in and out of wx (encoding issues?). It works in my testcases, but I'm not familiar enough to be sure if it always does. Finally, I've added a screenshot for those who don't want to rebuild :) So. Thoughts, and comments? Nice, it works quite well. Some thoughts: - My main concern is that I do use tab, which this prevents - as per your comment in the source I think we need an option to turn the feature off for those that don't want it. - A space should be added after an item has been inserted form the auto-complete list, per psql. - Schema-prefixed table names can't have columns in the WHERE clause auto-completed. Actually on further investigation this seems to apply to psql as well. - SELECT * FROM foo WHERE bar = 'FOO' AND doesn't work. Also as per psql? I'd like Andreas to look at this before applying - particularly the encoding bits which are still largely a mystery to me as well. Um, nicely spoken :-) I'll have a tight look at it, esp. the disable option. I'd be positively surprised if the feature can cope with my less than straight forward editing habits. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pgadmin crash issue
Daniel Whitter wrote:
Hello,
I've posted this mail to the postgresql general mailing list.
For those of you who don't read it:
I'm new to postgresql and during testing for a script I've found some
curious things.
If I do the following things a bad dump will be created that can't be
restored (using pgadmin3, pg_dump and pg_restore or psql).
There's also a issue that pgadmin crash.
In pgadmin3 do
1) Create a new db ('test_dump')
2) Create a new schema ('test_dump')
3) From schema 'pg_catalog' copy the lines from
CREATE OPERATOR <(... for <(abstime,abstime), <=(abstime,abstime),
=(abstime,abstime), >(abstime,abstime), >=(abstime,abstime)
and paste it in the query window. Write the schema name 'test_dump.'
before the operator sign and execute the query.
I've done this once for each operator.
4) Then copy the lines for operator class 'abstime_ops(btree)' from
schema 'pg_catalog' and paste it in the query window.
Write the schema name 'test_dump.' before the class and remove the
'default'. Then execute the query.
If you click on the created operator class in schema 'test_dump' you'll
get a error message box or on windows pgAdmin will crash.
The error message and the OS you're running on would be required to take
any action on this, and the complete query would be nice too.
Regards,
Andreas
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Website
Dave Page wrote: And where's the svn? Where it always was - svn://svn.pgadmin.org/trunk/www/ Hm, I did a svn update in my www dir and found it nearly empty afterwards. Note that all application-specific pages should go under pgadmin3/. 'k, so I see now what happened: most files moved up one level, while I have checked out www/pgadmin3 only. Good holiday? Yup. Very lazy: long sleeping, doing nothing, eating (lot of eating, need tight diet for the next weeks ;-) And no mails! Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Website
Dave, there are quite a lot of absolute paths, which makes the website on-runnable on my server (localhost/pgadmin3). Why not just relative paths throughout? 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] Website
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 19 January 2006 09:57 To: Dave Page Cc: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Website Dave, there are quite a lot of absolute paths, which makes the website on-runnable on my server (localhost/pgadmin3). Why not just relative paths throughout? It was that way originally, but I ran into some issues with $_SERVER['DOCUMENT_ROOT'] being incorrect (well, not being what I wanted). I forget what they were exactly now but the simple choice at the time was to not use relative paths and I later ended up changing them all for consistency. Feel free to figure out a fix if you like, or I can give you write access to wwwdevel or a new dedicated vhost on developer.pgadmin.org if you prefer. Problem is usage of DOCUMENT_ROOT. My localhost/pgadmin3 is not a doc root, but an alias. Seems the easiest fix is to add another virtual host on my machine. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgadmin-hackers] OSX tree renderer
Just noticed that the tree renderer under OSX uses those small triangles. On GTK, this is explicitely changed to use the line/+/- style renderer (pgAdmin3.cpp line 254ff). IMHO this should be used for clarity under OSX too, if not completely anti-MACish. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] SVN Commit by dpage: r4943 - trunk/www
[EMAIL PROTECTED] wrote: +# Run the translation cache update script: + +32 * * * * /usr/bin/wget -q -O /tmp/update.txt http://www.pgadmin.org/cache/update.php Doesn't work: wget cache/cache_translated.txt and cache/cache_outofdate.txt needed. 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: r4943 - trunk/www
Andreas Pflug wrote: [EMAIL PROTECTED] wrote: +# Run the translation cache update script: + +32 * * * * /usr/bin/wget -q -O /tmp/update.txt http://www.pgadmin.org/cache/update.php Doesn't work: wget cache/cache_translated.txt and cache/cache_outofdate.txt needed. Um... This certainly works on the website, I just need to see the page without actual *.txt creation. Discard previous post :-) Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: Andreas; have you had a chance to look at this yet? No, not yet. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-hackers] 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. * Adds the ability to delete a row to the pg_hba editor Hm, missed that? Probably thought disabling (commenting out) is enough. 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
Re: [pgadmin-hackers] Patch: Config editors
Magnus Hagander wrote: ly :-) maintain the file. Users are alreayd confused because pgadmin doesn't tell them that the "save your password" checkbox affects all non-pgadmin applications as well :-P (Yes, I've been bitten myself. And had to explain it to several others that hav ebeen..) You're right. How can we fix this? (not the mechanism, but the user confusion) Regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
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] 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=4965&view=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] 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] 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.5&content-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: Thanks, patch applied with minor tweaking re: trailing spaces as discussed on IM, and documentation. I eyeballed the multibyte handling, it looks ok to me. But I found some nasty misbehaviours: select * from pg_c - On Windows, a popup will appear. If you activate a different app (e.g. the debugger which runs pgadmin), it will stay on top. Only selecting the very ctlSqlBox window will let it disappear (this is the usual popup window fun...) - On Linux, pg_cast will appear instead of the popup. - On Linux, every will insert two \n, i.e. an additional empty line that can't be addressed with the cursor. This is also true if autotabcomplete is disabled (doesn't happen when reading a script from a file). Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Query tool: Autocompletion
Dave Page wrote: Thanks, patch applied with minor tweaking re: trailing spaces as discussed on IM, and documentation. More problems on Linux: - select * from pg_cpopup will show the same problem as on Windows, remaining on top of all windows. - All ctrl keys were executed twice, fixed in svn. Still, I'm not sure if event.m_metaDown=false shouldn't be active for OSX too. It has effect on function keys (F5 et al) - SELECT * FROM pg_class, pg_att won't do anything. - SELECT * FROM pg_class, pg_attribute WHERE will deliver pg_attribute columns only. - SELECT * FROM pg_class JOIN pg_attribute ON won't do anything. This renders the feature nearly useless. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] 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: 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. except for libxml2 not being there by default. 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 don't like storing more stuff in files, and in homedir even less. I even don't like registry/.pgadmin3 (not completely replacable), and would like some network (db) based solution to copy server connect strings from. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
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] Data type display
Peter Eisentraut wrote:
Is there a reason why pgAdmin uses internal type names like int2 everywhere,
whereas the supposedly user-friendly approach would be that external names
like smallint should be used. (Compare to the output of psql and pg_dump.)
You can obtain the friendly name using the backend function format_type,
which has been available at least since 7.3. This would also avoid the need
for manual concatenating with "[]" for array types.
I wasn't aware of that function back those days...
Also, the lists of data types you get when creating a table are not sorted
very well. The beginning seems to be alphabetical, but the geometry types
are at the end.
Perhaps, as an interface improvement, remove all the array types from the list
but instead make a separate checkbox "Array" instead.
pgAdmin uses the following query when retrieving valid types:
SELECT
typname, t.oid, CASE WHEN typelem > 0 THEN typelem ELSE t.oid END as
elemoid, typlen, typtype, nspname,
FROM pg_type t
JOIN pg_namespace nsp ON typnamespace=nsp.oid
WHERE typisdefined
AND typtype IN ('b', 'd')
ORDER BY CASE WHEN typtype='d' THEN 0 ELSE 1 END,
(t.typelem>0)::bool,
t.typname
serial and bigserial are added 'manually' if appropriate.
The goal was to have the types grouped: domain first, standard types
next, then array types.
I'm not too happy about the combobox at all, it's much too big. I'd
really like some hierarchical selection method, maybe a combobox with a
dropdown tree instead of a list. Wanted to implement this for ages now...
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] SQL display of inheriting tables wrong
Peter Eisentraut wrote: The SQL visualization of tables that inherit from another table is wrong in pgAdmin. You can check that with the table "emp" in the regression test database. The actual definition (as produced by pg_dump) is this: CREATE TABLE emp ( name text, age integer, "location" point, salary integer, manager name ) INHERITS (person); which is not the same we started out with. I'm not exactly sure what is going on here, but it's confusing. The columns are probably overloaded. The table code didn't obey the column's inherit flag, fixed in SVN for HEAD and 1.4, thanks for reporting. We didn't catch trying to edit an inherited column from the table dialog; corrected now 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] 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] SVN Commit by dpage: r4984 - trunk/pgadmin3
[EMAIL PROTECTED] wrote: Author: dpage Date: 2006-02-02 13:59:06 + (Thu, 02 Feb 2006) New Revision: 4984 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=4984&view=rev Log: Fix Andreas' dodgy formatting and attribution :-p Err, blasphemy? Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
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] 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
[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
