Thread: 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/468BB6FB.8050102@sun.com.html
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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian <bruce@momjian.us> 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. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH6dPA4QvfyHIvDvMRAj2AAKDQ2r2L8ztHDeUhBBSD10VwbttXugCgksd8 g8Tq27/AorIuM1Yo8nh1vbc= =JnjX -----END PGP SIGNATURE-----
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
Marc G. Fournier napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian <bruce@momjian.us>
> 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
On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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
Magnus Hagander napsal(a):
> On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote:
<snip>
>> 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
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: > > <snip> > > >> 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
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:
>> <snip>
>>
>>>> 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
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
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
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
Magnus Hagander <magnus@hagander.net> 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:
clusterdb initdb pg_resetxlog postmaster
createdb ipcclean pg_restore psql
createlang oid2name pg_standby reindexdb
createuser pg_config pgbench 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
Tom Lane napsal(a):
> Magnus Hagander <magnus@hagander.net> 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:
>
> clusterdb initdb pg_resetxlog postmaster
> createdb ipcclean pg_restore psql
> createlang oid2name pg_standby reindexdb
> createuser pg_config pgbench 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
Zdenek Kotala wrote: > Tom Lane napsal(a): > > Magnus Hagander <magnus@hagander.net> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Zdenek Kotala <Zdenek.Kotala@Sun.COM> 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
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> 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
Zdenek Kotala wrote: > Tom Lane napsal(a): >> Zdenek Kotala <Zdenek.Kotala@Sun.COM> 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
Andrew Dunstan napsal(a):
>
>
> Zdenek Kotala wrote:
>> Tom Lane napsal(a):
>>> Zdenek Kotala <Zdenek.Kotala@Sun.COM> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala <Zdenek.Kotala@Sun.COM> 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. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH6s4h4QvfyHIvDvMRAnUAAKCByD6R2Kvbf1zBaBQNOAsa2GHwhgCfRs99 s2xER8beIYpPCRsdsDJmLmA= =6oB1 -----END PGP SIGNATURE-----
On Wed, 26 Mar 2008 19:28:49 -0300 "Marc G. Fournier" <scrappy@hub.org> 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
Marc G. Fournier napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala
> <Zdenek.Kotala@Sun.COM> 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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Wednesday 26 March 2008 12:17, Andrew Dunstan wrote:
> Zdenek Kotala wrote:
> > Tom Lane napsal(a):
> >> Zdenek Kotala <Zdenek.Kotala@Sun.COM> 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