Re: [HACKERS] Script binaries renaming
On Wednesday 26 March 2008 12:17, Andrew Dunstan wrote:
> Zdenek Kotala wrote:
> > Tom Lane napsal(a):
> >> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> >>> Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same
> >>> output like pg_controldata. I think we can merge these commands.
> >>
> >> Now we're into change for the sake of change? Those programs don't
> >> have any naming problem.
> >
> > yes, but they are redundant
>
> Really? How so? They have overlapping functionality, but neither has a
> subset of the other's functionality.
>
> Possibly we should merge them, but that's a different issue, and in
> particular has nothing to do with renaming, so it doesn't belong in this
> thread.
>
Actually it does belong in this thread, at least in so much that we should
probably think about if we really want to do a bunch of command renaming when
there is a good chance we might want to change these names further in
subsequent releases to address real problems. (I'd be tempted to hold the
cosmetic changes untill we bump to 9.0 anyway, when backward
incompatabilities will make more sense)
One example of the above would be changing binaries to address the current
sub-par support for multiple versions of postgres on a single machine,
something like what debian/ubuntu have done with pg_lsclusters,
pg_initcluster, pg_ctlcluster, etc... istm a bad idea to rename initdb to
pg_init in the next release for what are mostly cosmetic reasons if in the
next 2 or 3 releases down the line we need to change it for more pratical
reasons.
(Side note: I know some people hate the debian changes to the various command
utilities because of the confusion it creates when trying to help people with
postgres; consider that at least those changes solve a class of problems, the
proposed changes will cause far more problems for end-users / helpers, and
for far less of a valid reason)
As for the problem faced by Sun, if they really have an issue with the naming
system, theres no reason they can't rename the binaries themselves to match
thier own naming standards since they control their own packages. I use
Solaris and this wouldn't bother me at all.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdenek Kotala wrote: > Thanks for correction. I don't have yet PG8.3 on my production server and > I was convinced with good autovacuum marketing that is "ultimate > solution". :-) It is not perfect yet. It's improving -- keep in mind it's rather new. However, I doubt "vacuumdb -a" is the thing to use when autovac is "not good enough", because in those cases what typically happens is that there are huge tables, or tables with high update rates, so a simple vacuum-all-tables-in-all-databases would be similarly useless. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Marc G. Fournier napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala <[EMAIL PROTECTED]> wrote: Minimal me :-) and Solaris Architect committee have complain. Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. Huh? I run a vacuumdb once a week on all my databases, even with autovacuum turned on Thanks for correction. I don't have yet PG8.3 on my production server and I was convinced with good autovacuum marketing that is "ultimate solution". :-) Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
On Wed, 26 Mar 2008 19:28:49 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > Huh? I run a vacuumdb once a week on all my databases, even with > autovacuum turned on Yeah I have to agree. Autovacuum only solves the common data issues. There are still many, many issues that it can't solve. Although 8.3 is a huge step forward. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [HACKERS] Script binaries renaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala <[EMAIL PROTECTED]> wrote: > Minimal me :-) and Solaris Architect committee have complain. Question is > also how many users really use these commands. For example vacuumdb is not > too important now when we have autovacuum. Huh? I run a vacuumdb once a week on all my databases, even with autovacuum turned on - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH6s4h4QvfyHIvDvMRAnUAAKCByD6R2Kvbf1zBaBQNOAsa2GHwhgCfRs99 s2xER8beIYpPCRsdsDJmLmA= =6oB1 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Andrew Dunstan napsal(a): Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change? Those programs don't have any naming problem. yes, but they are redundant Really? How so? They have overlapping functionality, but neither has a subset of the other's functionality. Sorry, overlapping is better word. Possibly we should merge them, but that's a different issue, and in particular has nothing to do with renaming, so it doesn't belong in this thread. Ok. Agree. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change? Those programs don't have any naming problem. yes, but they are redundant Really? How so? They have overlapping functionality, but neither has a subset of the other's functionality. Possibly we should merge them, but that's a different issue, and in particular has nothing to do with renaming, so it doesn't belong in this thread. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: There's an awful lot of names here that don't have any obvious connection to Postgres ... Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change? Those programs don't have any naming problem. yes, but they are redundant and I think when we start a cleaning and polishing it should be done completely. But names are correct :-) Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdenek Kotala <[EMAIL PROTECTED]> writes: >> There's an awful lot of names here that don't have any obvious >> connection to Postgres ... > Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same > output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change? Those programs don't have any naming problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdenek Kotala wrote: > Tom Lane napsal(a): > > Magnus Hagander <[EMAIL PROTECTED]> writes: > >> Another option then might be to simply deprecate their use, and > >> eventually get rid of them, instead of renaming them? > > > > I'd like to get rid of ipcclean immediately; it hasn't had any usefulness > > in years. > > +1 I have just posted a patch for this. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Tom Lane napsal(a): Magnus Hagander <[EMAIL PROTECTED]> writes: Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? I'd like to get rid of ipcclean immediately; it hasn't had any usefulness in years. +1 The issue is larger than the proposed patch addresses, though. I see the following stuff installed in .../bin by CVS HEAD: clusterdbinitdb pg_resetxlog postmaster createdb ipcclean pg_restore psql createlang oid2name pg_standby reindexdb createuser pg_configpgbench vacuumdb dropdb pg_controldata pltcl_delmod vacuumlo droplang pg_ctl pltcl_listmod dropuser pg_dump pltcl_loadmod ecpg pg_dumpall postgres There's an awful lot of names here that don't have any obvious connection to Postgres ... Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Magnus Hagander <[EMAIL PROTECTED]> writes: > Another option then might be to simply deprecate their use, and > eventually get rid of them, instead of renaming them? I'd like to get rid of ipcclean immediately; it hasn't had any usefulness in years. The issue is larger than the proposed patch addresses, though. I see the following stuff installed in .../bin by CVS HEAD: clusterdbinitdb pg_resetxlog postmaster createdb ipcclean pg_restore psql createlang oid2name pg_standby reindexdb createuser pg_configpgbench vacuumdb dropdb pg_controldata pltcl_delmod vacuumlo droplang pg_ctl pltcl_listmod dropuser pg_dump pltcl_loadmod ecpg pg_dumpall postgres There's an awful lot of names here that don't have any obvious connection to Postgres ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdeněk Kotala wrote: Andrew Dunstan napsal(a): Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb rather than using autovacuum. Yes, up to 8.2, but I think situation for 8.3 could be different. We have more works, autovacuum is better and so on. Again, this is just not true. It might not be a situation you run across, but autovacuum does not suit all needs. This includes 8.3. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Andrew Dunstan napsal(a): Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb rather than using autovacuum. Yes, up to 8.2, but I think situation for 8.3 could be different. We have more works, autovacuum is better and so on. Incidentally, I am less opposed than some to some sensible renaming here, eventually. Perhaps we could take the opportunity to fix the naming of initdb, which confuses the heck out of many people. Instead of renaming initdb extend pg_ctl (pg_ctl init) seems to me as a better idea. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb rather than using autovacuum. Incidentally, I am less opposed than some to some sensible renaming here, eventually. Perhaps we could take the opportunity to fix the naming of initdb, which confuses the heck out of many people. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Magnus Hagander napsal(a): On Wed, 2008-03-26 at 13:21 +0100, Zdeněk Kotala wrote: Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scripts that I've come across also do that. So I'm not sure exactly how important it is. Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? In one of my mail I also mentioned to replace all of these commands by one (e.g. pg_cmd) which will integrate all of them. Removing is not good solution for people who writes scripts, because process psql output is complicated and there is not easy way how to run vacuum on all databases for example. You can add lots of nice parameters to psql to make it quite easy to process the output. Running vacuum on all databases isn't particularly hard - but it does require a small bit of shell-fu. Yes, it needs extra lines in shell script and probably most of use cases are possible do by psql command. Maybe removing will be better solution. > But I'll grant you that one for vacuumdb. I was specifically thinking about the create/drop user/db/lang scripts, which are the ones likely to "conflict" with other parts of the system. Didn't think of vacuumdb. I see. I think that autovacuum stops usage of vacuumdb command anyway. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
On Wed, 2008-03-26 at 13:21 +0100, Zdeněk Kotala wrote: > Magnus Hagander napsal(a): > > On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: > > > > >> Are we really prepared to break everyone's scripts for this? > > > > I wonder how many people actually use those commands :-) I know I always > > use psql with a commandline parameter, and the majority of other peoples > > scripts that I've come across also do that. So I'm not sure exactly how > > important it is. > > > > Another option then might be to simply deprecate their use, and > > eventually get rid of them, instead of renaming them? > > In one of my mail I also mentioned to replace all of these commands by one > (e.g. > pg_cmd) which will integrate all of them. Removing is not good solution for > people who writes scripts, because process psql output is complicated and > there > is not easy way how to run vacuum on all databases for example. You can add lots of nice parameters to psql to make it quite easy to process the output. Running vacuum on all databases isn't particularly hard - but it does require a small bit of shell-fu. But I'll grant you that one for vacuumdb. I was specifically thinking about the create/drop user/db/lang scripts, which are the ones likely to "conflict" with other parts of the system. Didn't think of vacuumdb. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scripts that I've come across also do that. So I'm not sure exactly how important it is. Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? In one of my mail I also mentioned to replace all of these commands by one (e.g. pg_cmd) which will integrate all of them. Removing is not good solution for people who writes scripts, because process psql output is complicated and there is not easy way how to run vacuum on all databases for example. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Where are we on this? Tom thinks we don't want this. TODO has: > > * Prefix command-line utilities like createuser with 'pg_' > > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php > > It wasn't just me; quite a few people were dubious about it when the > patch was submitted. See the thread here: > http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php > > > One idea is to keep the existing commands and just add pg_* (or pg*) to > > additional versions, with the idea that the original versions will be > > removed some day. > > AFAICS the only argument for doing this is to eliminate confusion and > potential conflicts, which means that we get no benefit at all until we > actually do remove the old names. So if we're going to do this, we have > to make a commitment that we're going to remove the old names within the > reasonably foreseeable future (say, about two releases out). > > Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scripts that I've come across also do that. So I'm not sure exactly how important it is. Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Marc G. Fournier napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Uh, I think it is hard to make a case that 'createuser' is an appropriate name for a Postgres utility. On the other hand, we haven't had many complaints about it, which is kind of odd. If nobody has ever complained, what is the reason for the change? How many ppl are going to complain because the commands they are used to "suddenly stop existing"? Minimal me :-) and Solaris Architect committee have complain. Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. You can specify tablespace in createdb command but you don't have createtablespace command and so on. I will send survey to general list today and I hope we get some useful information. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Bruce Momjian napsal(a): Where are we on this? Tom thinks we don't want this. TODO has: I plan to send survey on general list about it today. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: > Uh, I think it is hard to make a case that 'createuser' is an > appropriate name for a Postgres utility. On the other hand, we haven't > had many complaints about it, which is kind of odd. If nobody has ever complained, what is the reason for the change? How many ppl are going to complain because the commands they are used to "suddenly stop existing"? - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH6dPA4QvfyHIvDvMRAj2AAKDQ2r2L8ztHDeUhBBSD10VwbttXugCgksd8 g8Tq27/AorIuM1Yo8nh1vbc= =JnjX -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Where are we on this? Tom thinks we don't want this. TODO has: > > * Prefix command-line utilities like createuser with 'pg_' > > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php > > It wasn't just me; quite a few people were dubious about it when the > patch was submitted. See the thread here: > http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php True. > > One idea is to keep the existing commands and just add pg_* (or pg*) to > > additional versions, with the idea that the original versions will be > > removed some day. > > AFAICS the only argument for doing this is to eliminate confusion and > potential conflicts, which means that we get no benefit at all until we > actually do remove the old names. So if we're going to do this, we have > to make a commitment that we're going to remove the old names within the > reasonably foreseeable future (say, about two releases out). > > Are we really prepared to break everyone's scripts for this? Uh, I think it is hard to make a case that 'createuser' is an appropriate name for a Postgres utility. On the other hand, we haven't had many complaints about it, which is kind of odd. I feel people can always symlink in the old names if they still want them after we remove the old names. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Script binaries renaming
Bruce Momjian <[EMAIL PROTECTED]> writes: > Where are we on this? Tom thinks we don't want this. TODO has: > * Prefix command-line utilities like createuser with 'pg_' > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php It wasn't just me; quite a few people were dubious about it when the patch was submitted. See the thread here: http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php > One idea is to keep the existing commands and just add pg_* (or pg*) to > additional versions, with the idea that the original versions will be > removed some day. AFAICS the only argument for doing this is to eliminate confusion and potential conflicts, which means that we get no benefit at all until we actually do remove the old names. So if we're going to do this, we have to make a commitment that we're going to remove the old names within the reasonably foreseeable future (say, about two releases out). Are we really prepared to break everyone's scripts for this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Script binaries renaming
Where are we on this? Tom thinks we don't want this. TODO has: * Prefix command-line utilities like createuser with 'pg_' http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php See for reference: http://momjian.us/mhonarc/patches/[EMAIL PROTECTED] One idea is to keep the existing commands and just add pg_* (or pg*) to additional versions, with the idea that the original versions will be removed some day. --- Zdenek Kotala wrote: > I attach complete patch which renames following binaries > > createdb createlang createuser dropdb droplang dropuser clusterdb > vacuumdb reindexdb > > to > > pg_createdb pg_createlang pg_createuser pg_dropdb pg_droplang > pg_dropuser pg_clusterdb pg_vacuumdb pg_reindexdb > > Symlinks (or copy on win32) are created for backward compatibility. > > This renaming was discussed there: > > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00145.php > > I create also separate unified patch for documentation. > > Zdenek [ application/x-gzip is not supported, skipping... ] > > ---(end of broadcast)--- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
