Re: [PATCHES] Admin functions contrib
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 29 July 2004 18:41 To: Andreas Pflug Cc: Bruce Momjian; PostgreSQL Patches; Dave Page Subject: Re: [PATCHES] Admin functions contrib Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] win32 crash in initdb
The crash people are getting in initdb is due to the 1.19 revision to pgtz.c. Not sure why yet...looking into it... Unfortunate behavior when probing pre-1970 dates, maybe? Indeed that was the problem. Attached patch fixes the issue here and for Merlin :-) I've also figured out why it always worked for me. When in the western europe timezone, the bug does not show up (probably because we don't probe those dates). When I set my system to US Eastern, it broke. Here we go again with a more correct patch, per Toms comments and hints off-list. //Magnus tzfix.patch Description: tzfix.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 version info
Perhaps a compromise would be to set versioninfo on libpq.dll (which we alerady do), and on all the EXEs, and ignore the rest of the DLLs. It's not ideal, but it's a great deal better than nothing at all. If that is an option, why not just put versions into the build-time linkable DLLs, which really need a version, and leave it out for the rest. Clearly, we cannot put a version into every file anyway (headers files, etc.), so everything must have a version does not hold anyway, unless there is some weird rule again that certain things must have one. As for DLLs, yes, that sounds reasonable. We also need to put it on the EXEs. That would mean which DLLS? libpq.dll and pgevent.dll definitly. Any of the ecpg dlls? If we limit ourselves to these libs, are you fine with keeping the 7.5.x version numbering there? (As said before, for libpq we don't have much choice, and pgevent.dll has no other versioning scheme anyway, since it's brand new and win32 only) As said, not ideal, but good enough I think. I think the rule generally is any EXE and DLL. But as long as it's a private DLL that nobody else ever uses, I think it's reasonable to skip the rule there. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Admin functions contrib
Dave Page wrote: As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. If you're curious what Bruce has seen, it was this: http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png The size functions will offer this: http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 version info
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 30 July 2004 09:58 To: Peter Eisentraut Cc: Andrew Dunstan; [EMAIL PROTECTED] Subject: Re: [PATCHES] win32 version info Perhaps a compromise would be to set versioninfo on libpq.dll (which we alerady do), and on all the EXEs, and ignore the rest of the DLLs. It's not ideal, but it's a great deal better than nothing at all. If that is an option, why not just put versions into the build-time linkable DLLs, which really need a version, and leave it out for the rest. Clearly, we cannot put a version into every file anyway (headers files, etc.), so everything must have a version does not hold anyway, unless there is some weird rule again that certain things must have one. As for DLLs, yes, that sounds reasonable. We also need to put it on the EXEs. That would mean which DLLS? libpq.dll and pgevent.dll definitly. Any of the ecpg dlls? If we limit ourselves to these libs, are you fine with keeping the 7.5.x version numbering there? (As said before, for libpq we don't have much choice, and pgevent.dll has no other versioning scheme anyway, since it's brand new and win32 only) As said, not ideal, but good enough I think. I think the rule generally is any EXE and DLL. But as long as it's a private DLL that nobody else ever uses, I think it's reasonable to skip the rule there. //Magnus I've just had a look at a Linux install of 7.4.2 and the version numbering that is present in the /lib and /bin directories. To make things consistent, I would suggest the following approach for applying version information on a per directory basis: /bin- release numbering, e.g. 7.5.x for all EXE/DLL /lib- library numbering, e.g. libpq.dll should be version 3.1, libecpg.dll should be version 4.1 for all DLL /lib/postgresql - release numbering, e.g. 7.5.x for all DLL since these DLLs are used internally by the PostgreSQL server There doesn't seem much point in versioning anything else. To me, it makes more sense to version the libraries such as libpq.dll like their UNIX-based counterparts so the version numberings are consistent between the two. I can see a scenario using release numbering where an application linked to libpq.dll could fail if it checked to ensure the version matched the one it expected, even though an upgrade would not always be necessary if the FE/BE protocol remained unchanged; here the library numbering gives the better indication of the capabilities of the DLL, since any changes in protocol behaviour would be reflected by a change in the major/minor of the version number. Incidentally I've just noticed from my Win32 build a couple of months back that /lib and /lib/postgresql have been combined into /lib. Would this make it more difficult to have different versioning schemes for internal PostgreSQL libraries and the external client libraries as suggested above? Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: Dave Page wrote: As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. If you're curious what Bruce has seen, it was this: http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png The size functions will offer this: http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Yep, that's what I saw. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Admin functions contrib
Dave Page wrote: Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Ouch, that is a powerful argument! The big problem is that we are designing features a month after feature freeze. Not that the ideas weren't around before feature freeze, but they are still not solid from a community agreement perspective. Let's get the logging working and then figure out what to do, OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pgxs: build infrastructure for extensions v4
Applied by Peter. --- Fabien COELHO wrote: Dear patchers, Please find attached another new version of a patch which provides a working infrastructure for pg extensions. I hope it addresses all of Peter's comments. I'll be away for the next 3 weeks, so if minor changes are required it would be best if you could proceed without me... The infrastructure is a simple reworking of the already available internal infrastructure for contrib, so that it can be used outside of the postgresql source tree after installation, without gory details being in sight of the user. The documentation is added as a new section in xfunc.sgml. I updated all contrib makefiles so that they can be used either the standard way after a configure, or the new way without needing a configure but with an already installed postgreSQL. Just try them with cd contrib/foo ; make USE_PGXS=1 install *AFTER* postgresql has been configure, compiled and installed. It should be compiled and installed wrt to the first pg_config which is found in the path. How it works: - necessary files (includes, scripts, makefiles...) are copied under $(pkglibdir)/pgxs on the initial make install. due to gnu-make restriction on how its includes work, these files must be copied with the *same* directory structure as the pg source tree. The fact does not appear at all in the actual infrastructure from the user point of view, but it explains why subdirectories are necessary under pgxs, if you care to have a look. - the makefile of any extension is expected to set macro PGXS to pg_config --pgxs, to include a special makefile, and to set some macros depending on what is to be built, just like in current contrib. - I've added two PGXS-triggered conditionnals in Makefile.global, so that includes and libraries are taken where needed. Notes: - there is still a light-install target that matches the previous install behavior, as new install matches previous server-install. - I'm not sure the sgml is ok. It looks ok, but is it enough. - It validates and works for me. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] win32 crash in initdb
Magnus Hagander [EMAIL PROTECTED] writes: Here we go again with a more correct patch, per Toms comments and hints off-list. Applied. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] win32 timezone map
Per discussion off-list with Tom, here is a patch to redo the way the system timezone is detected on win32. Instead of trying to figure out what to do, it just looks in a lookup table for all available timezones (there is a finite and stable number of timezones on a win32 system, unlike unixes that can have timezones added manually in most cases). I've tried to match the timezones as good as I could using the city names from the win32 descriptions and using some google. There are probably some that can have better mappings - local knowledge is probably the key there. In passing the patch also removes some of the kludges put in the tz detection code that were specific for win32. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] win32 timezone map
Magnus Hagander [EMAIL PROTECTED] writes: Per discussion off-list with Tom, here is a patch to redo the way the system timezone is detected on win32. Er ... no patch attached? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. --- Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 29 July 2004 18:41 To: Andreas Pflug Cc: Bruce Momjian; PostgreSQL Patches; Dave Page Subject: Re: [PATCHES] Admin functions contrib Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] Fix for initdb translation
Attached is an applied fix for initdb translation for po/zh_TW.po.
Without it I get these errors:
gmake[3]: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/bin/initdb'
msgfmt -o po/de.mo po/de.po
msgfmt -o po/fr.mo po/fr.po
msgfmt -o po/it.mo po/it.po
msgfmt -o po/pt_BR.mo po/pt_BR.po
msgfmt -o po/ru.mo po/ru.po
msgfmt -o po/sv.mo po/sv.po
msgfmt -o po/zh_TW.mo po/zh_TW.po
po/zh_TW.po:199: `msgid' and `msgstr' entries do not both end with '\n'
po/zh_TW.po:260: illegal control sequence
po/zh_TW.po:471: illegal control sequence
found 3 fatal errors
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/initdb/po/zh_TW.po
===
RCS file: /cvsroot/pgsql-server/src/bin/initdb/po/zh_TW.po,v
retrieving revision 1.1
diff -c -c -r1.1 zh_TW.po
*** src/bin/initdb/po/zh_TW.po 30 Jul 2004 05:28:36 - 1.1
--- src/bin/initdb/po/zh_TW.po 31 Jul 2004 04:38:34 -
***
*** 197,203
#: initdb.c:1864
msgid ok\n
! msgstr ¦¨¥\\n
#: initdb.c:1894
#, c-format
--- 197,203
#: initdb.c:1864
msgid ok\n
! msgstr ¦¨¥\n
#: initdb.c:1894
#, c-format
***
*** 257,263
#: initdb.c:1973
msgid --no-locale equivalent to --locale=C\n
! msgstr --no-locale ¥\¯à¦P --locale=C\n
#: initdb.c:1974
msgid -U, --username=NAME database superuser name\n
--- 257,263
#: initdb.c:1973
msgid --no-locale equivalent to --locale=C\n
! msgstr --no-locale ¥¯à¦P --locale=C\n
#: initdb.c:1974
msgid -U, --username=NAME database superuser name\n
***
*** 468,474
\n
msgstr
\n
! °õ¦æ¦¨¥\¡A²{¦b§A¥i¥H¥Î¤U¦C©R¥O±Ò°Ê¸ê®Æ®w¦øªA¾¹:\n
\n
%s%s%s/postmaster -D %s%s%s\n
©Î\n
--- 468,474
\n
msgstr
\n
! °õ¦æ¦¨¥¡A²{¦b§A¥i¥H¥Î¤U¦C©R¥O±Ò°Ê¸ê®Æ®w¦øªA¾¹:\n
\n
%s%s%s/postmaster -D %s%s%s\n
©Î\n
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Looks good. I will have to do a little adjustment because dirmod is currently only used by Win32. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Andrew Dunstan wrote: Bruce Momjian wrote: Andrew Dunstan wrote: I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. Great. Thanks. Sorry I delayed addressing this for so long. Please check the enclosed patch to see if it does what you want. Should we look at replacing cp/copy in 7.6? probably. Put it as a possible TODO maybe. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
