script binaries renaming

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

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.

A couple of comments:

Do we actually need to remove and recreate the documentation files?
Can't we keep the source files and just have it generate the man pages
and other references with the outputname pg_xyz?

Should we be installing symlinks or at least a placeholder manpage for
the old commandnames (maybe a single man page for all the old commands
saying "prefix pg_ to get this command") the same way it's done for the
binaries? (my apologies if it already does this, I don't know exactly
how the man pages are generated from the sgml. I just noticed there was
no makefile modified in the docs area)

I'm also not sure we really should install copies on win32. Given how
seldom these commands are actually used on windows (most people really
use pgadmin to do these things).

Also, your patch does not touch the msvc buildsystem, which will still
be generating files with the old name.

//Magnus

Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
> I attach complete patch which renames following binaries
>
> createdb createlang createuser dropdb droplang dropuser clusterdb
> vacuumdb reindexdb

I just want to say I dislike this idea.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Donnerstag, 5. Juli 2007 06:59 schrieb Magnus Hagander:
> I'm also not sure we really should install copies on win32. Given how
> seldom these commands are actually used on windows

But some people do use them, and they should have the same experience as on
any other platform. I don't think disk space is really a concern, is it?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>> I attach complete patch which renames following binaries
>>
>> createdb createlang createuser dropdb droplang dropuser clusterdb
>> vacuumdb reindexdb
>
> I just want to say I dislike this idea.

This is almost as bad as Magnus agreeing with JD (!), but I agree with
Peter :-). After years of typing the current names, changing them does
seem somewhat annoying. Worse yet, pg_* is just awkward to type.

/D

On Jul 6, 2007, at 5:53 , Dave Page wrote:

> On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
>> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>>> I attach complete patch which renames following binaries
>>>
>>> createdb createlang createuser dropdb droplang dropuser clusterdb
>>> vacuumdb reindexdb
>>
>> I just want to say I dislike this idea.
>
> This is almost as bad as Magnus agreeing with JD (!), but I agree with
> Peter :-). After years of typing the current names, changing them does
> seem somewhat annoying. Worse yet, pg_* is just awkward to type.

While the change might be awkward, the names of these binaries really
should be namespaced in some way. The current just too generic to be
throwing into a bin/ directory in my opinion.

Michael Glaesemann
grzm seespotcode net

Michael Glaesemann wrote:
>
> On Jul 6, 2007, at 5:53 , Dave Page wrote:
>
>> On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
>>> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>>>> I attach complete patch which renames following binaries
>>>>
>>>> createdb createlang createuser dropdb droplang dropuser clusterdb
>>>> vacuumdb reindexdb
>>>
>>> I just want to say I dislike this idea.
>>
>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>> Peter :-). After years of typing the current names, changing them does
>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>
> While the change might be awkward, the names of these binaries really
> should be namespaced in some way. The current just too generic to be
> throwing into a bin/ directory in my opinion.

Why should they be name spaced? I see zero reason why that should be the
case...

apache_httpd?
gnu_ls?

The only obvious name spaced applications out there are in the G/K world
of nome and de.

Joshua D. Drake

>
> Michael Glaesemann
> grzm seespotcode net
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Michael Glaesemann wrote:
>
> On Jul 6, 2007, at 5:53 , Dave Page wrote:
>
>> On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
>>> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>>>> I attach complete patch which renames following binaries
>>>>
>>>> createdb createlang createuser dropdb droplang dropuser clusterdb
>>>> vacuumdb reindexdb
>>>
>>> I just want to say I dislike this idea.
>>
>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>> Peter :-). After years of typing the current names, changing them does
>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>
> While the change might be awkward, the names of these binaries really
> should be namespaced in some way. The current just too generic to be
> throwing into a bin/ directory in my opinion.

Of course I realize that I voted for the idea in the first place. I
voted for it for consistency more than anything but as I think about it,
it really is clunky and doesn't serve any real purpose.

Joshua D. Drake

>
> Michael Glaesemann
> grzm seespotcode net
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Jul 6, 2007, at 11:28 , Joshua D. Drake wrote:

> Why should they be name spaced? I see zero reason why that should
> be the case...
>
> apache_httpd?
> gnu_ls?

Personally, I think that the Apache daemon *should* be named apached
or something along those lines.

Compare with postgres, pg_ctl, pg_dump, or pg_config. Albeit postgres
is not consistent, they're all easily identifiable with PostgreSQL.
In my opinion, postgres, pg_ctl, pg_ccmp, and pg_config are better
names than, say, dbmsd, dbms_ctl, db_dump, and db_config. Also, we
recently deprecated the use of postmaster (easily confused with mail
systems) in favor of postgres. Looking at the binaries that are
installed for 8.2:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
ecpg
initdb
ipcclean
pg_config
pg_controldata
pg_ctl
pg_dump
pg_dumpall
pg_resetxlog
pg_restore
postgres
postmaster -> postgres
psql
reindexdb
vacuumdb

If these are all dumped into /usr/local/bin (as they sometimes are),
many of them are not readily identifiable with PostgreSQL. Shouldn't
they be? Compare with Subversion:
svn
svnadmin
svndumpfileter
svnlook
svnserver
svnsync
svnversion

I find these names much more consistent.

Michael Glaesemann
grzm seespotcode net

Magnus Hagander wrote:
> 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.
>
> A couple of comments:
>
> Do we actually need to remove and recreate the documentation files?
> Can't we keep the source files and just have it generate the man pages
> and other references with the outputname pg_xyz?

I used postmaster/postgresql as a pattern for makefile and documentation
changes.

> Should we be installing symlinks or at least a placeholder manpage for
> the old commandnames (maybe a single man page for all the old commands
> saying "prefix pg_ to get this command") the same way it's done for the
> binaries? (my apologies if it already does this, I don't know exactly
> how the man pages are generated from the sgml. I just noticed there was
> no makefile modified in the docs area)

I'm not guru on documentation building, but there are driver files which
contains list of files - see reference.sgml and ref/allfiles.sgml.

I copied decription from current pages to new pg_* files. In old files I
only keep mention that it is obsolete command. See postmaster
documentation.

> I'm also not sure we really should install copies on win32. Given how
> seldom these commands are actually used on windows (most people really
> use pgadmin to do these things).

Postmaster does same thing.

> Also, your patch does not touch the msvc buildsystem, which will still
> be generating files with the old name.

Hmm. I do not nothing about it :(. I need help there.

Thank for your comments

Zdenek

Zdenek Kotala wrote:
>> I'm also not sure we really should install copies on win32. Given how
>> seldom these commands are actually used on windows (most people really
>> use pgadmin to do these things).
>
> Postmaster does same thing.

Actually, the win32 distribution only ships postgres.exe, not
postmaster.exe.

>> Also, your patch does not touch the msvc buildsystem, which will still
>> be generating files with the old name.
>
> Hmm. I do not nothing about it :(. I need help there.

Actually, now that I look at it it seems like most of it comes out
automatically from the Makefile parser. We'll just have to test that if
the patch ends up being accepted (as there seems to be some discussion
about that...)

//Magnus

Dave Page wrote:
> On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
>> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>>> I attach complete patch which renames following binaries
>>>
>>> createdb createlang createuser dropdb droplang dropuser clusterdb
>>> vacuumdb reindexdb
>> I just want to say I dislike this idea.
>
> This is almost as bad as Magnus agreeing with JD (!), but I agree with
> Peter :-). After years of typing the current names, changing them does
> seem somewhat annoying. Worse yet, pg_* is just awkward to type.

But these utilities are mostly using in scripts -> one type, multi use.
I think, most users prefer psql for interactive typing.

Zdenek

Joshua D. Drake wrote:
> Michael Glaesemann wrote:
>>
>> On Jul 6, 2007, at 5:53 , Dave Page wrote:
>>
>>> On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote:
>>>> Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala:
>>>>> I attach complete patch which renames following binaries
>>>>>
>>>>> createdb createlang createuser dropdb droplang dropuser clusterdb
>>>>> vacuumdb reindexdb
>>>>
>>>> I just want to say I dislike this idea.
>>>
>>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>>> Peter :-). After years of typing the current names, changing them does
>>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>>
>> While the change might be awkward, the names of these binaries really
>> should be namespaced in some way. The current just too generic to be
>> throwing into a bin/ directory in my opinion.
>
> Of course I realize that I voted for the idea in the first place. I
> voted for it for consistency more than anything but as I think about it,
> it really is clunky and doesn't serve any real purpose.
>

There is group of people who has different opinion. The main reasons for
this patch are 1) names could collide with system tools 2) it is
confusing for lot of users - typically for newbies and me :-) 3) it is
not consistent with naming convention.

I started to use postgres since version 6.5 and these names of script
utilities are still confusing for me.

By the way my original idea was create new command "pg_cmd", which
integrates all in one include missing commands(e.g. createtablespace).

Zdenek

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Dave Page wrote:
>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>> Peter :-). After years of typing the current names, changing them does
>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.

> But these utilities are mostly using in scripts -> one type, multi use.

According to whom? The ones that are really at issue I think are
createuser/createlang/dropuser/droplang, and those seem mainly intended
for interactive use. In a script you might as well use psql -c.

The ones that have "db" in the name do not seem to me to need renaming.
While maybe not obviously connected to Postgres, the chance of a
collision with some other project is low.

One that I'd personally vote to remove completely is "ipcclean".
It's always been a crude, incomplete hack anyway, and the reason
no one has bothered to improve it is that there is next to no use
for it anymore.

regards, tom lane

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> There is group of people who has different opinion. The main reasons for
> this patch are 1) names could collide with system tools

That argument is purely theoretical, though, since no one has complained
to us of an *actual* collision. With these utilities having been around
with their current names for more than ten years, I think we've
established sufficient squatter's rights on the names ;-). No doubt
we'd do it differently if starting in a green field, but we're not
starting in a green field. There's enough usage precedent now that I
doubt we can ever remove the existing names, which leaves me wondering
what is the point.

> By the way my original idea was create new command "pg_cmd", which
> integrates all in one include missing commands(e.g. createtablespace).

There doesn't seem to be anyone but you who feels any attraction to that
concept. These utilities have a wide enough difference in behavior and
intended usage that ISTM force-fitting them into a single binary would
just increase confusion and difficulty of use.

regards, tom lane

On Jul 7, 2007, at 13:50 , Tom Lane wrote:

> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> Dave Page wrote:
>>> This is almost as bad as Magnus agreeing with JD (!), but I agree
>>> with
>>> Peter :-). After years of typing the current names, changing them
>>> does
>>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>
>> But these utilities are mostly using in scripts -> one type, multi
>> use.
>
> According to whom? The ones that are really at issue I think are
> createuser/createlang/dropuser/droplang, and those seem mainly
> intended
> for interactive use. In a script you might as well use psql -c.

I'm curious as to know how often these are used at all. I think I may
have used createuser once and used to use createlang, but I can't
recall ever using the others.

Michael Glaesemann
grzm seespotcode net

On 7/7/07, Michael Glaesemann <grzm(at)seespotcode(dot)net> wrote:
> I'm curious as to know how often these are used at all. I think I may
> have used createuser once and used to use createlang, but I can't
> recall ever using the others.
>

i used to use createlang before the pg_pltemplate exists (because i
hate to have to create those pl handlers at hand). after that the only
script that has a real use to me is initdb and pg_ctl

what makes me wonder why doesn't exist "pg_ctl init"

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

Michael Glaesemann wrote:
>
> On Jul 7, 2007, at 13:50 , Tom Lane wrote:
>
>> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>>> Dave Page wrote:
>>>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>>>> Peter :-). After years of typing the current names, changing them does
>>>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>>
>>> But these utilities are mostly using in scripts -> one type, multi use.
>>
>> According to whom? The ones that are really at issue I think are
>> createuser/createlang/dropuser/droplang, and those seem mainly intended
>> for interactive use. In a script you might as well use psql -c.
>
> I'm curious as to know how often these are used at all. I think I may
> have used createuser once and used to use createlang, but I can't recall
> ever using the others.
>
> Michael Glaesemann
> grzm seespotcode net
>

I use createuser, createdb all the time, as well as createlang from time
to time. I never use the drop versions.

Regards, Dave

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> There is group of people who has different opinion. The main reasons for
>> this patch are 1) names could collide with system tools
>
> That argument is purely theoretical, though, since no one has complained
> to us of an *actual* collision. With these utilities having been around
> with their current names for more than ten years, I think we've
> established sufficient squatter's rights on the names ;-).

You have right on linux/*bsd world where postgres is squatter :-) for long time.
But in Solaris world (and probably in HP-UX, AIX...) postgresql does not have
established these squatter's rights. And names as "createuser" is something like
reserved keyword for OS utilities.

Zdenek

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> Dave Page wrote:
>>> This is almost as bad as Magnus agreeing with JD (!), but I agree with
>>> Peter :-). After years of typing the current names, changing them does
>>> seem somewhat annoying. Worse yet, pg_* is just awkward to type.
>
>> But these utilities are mostly using in scripts -> one type, multi use.
>
> According to whom? The ones that are really at issue I think are
> createuser/createlang/dropuser/droplang, and those seem mainly intended
> for interactive use. In a script you might as well use psql -c.
>
> The ones that have "db" in the name do not seem to me to need renaming.
> While maybe not obviously connected to Postgres, the chance of a
> collision with some other project is low.

Yes, but if we rename four why does it do for all of them?

> One that I'd personally vote to remove completely is "ipcclean".
> It's always been a crude, incomplete hack anyway, and the reason
> no one has bothered to improve it is that there is next to no use
> for it anymore.

And what's about remove all script commands? Everybody can use psql -c and it
decreases amount of code. Initdb should be replaced by pg_ctl init command. We
can plan it for Postgresql 9.0 as a main change :-).

Zdenek

Jaime Casanova wrote:

>
> what makes me wonder why doesn't exist "pg_ctl init"
>

I suggested it in previous discussion on hackers. See

http://archives.postgresql.org/pgsql-hackers/2007-06/msg00142.php

Zdenek

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

I think we need to make a decision.

---------------------------------------------------------------------------

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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

> I think we need to make a decision.

Well, I don't have any particular objection to adding pg_ prefixes
as alternate names for the existing scripts. However, it's not clear
what is the point unless we have the intention to remove the old names
at some time in the foreseeable future. And the consensus of the
previous thread on -patches seemed to be that nobody except Zdenek
was very eager to do that.

In any case, there is no value in discussing this further on -patches
since the readers of this list already weighed in. If you want to
make a decision then it needs to be made on -hackers or -general.

regards, tom lane

Tom Lane napsal(a):
> Bruce Momjian <bruce(at)momjian(dot)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
>
>> I think we need to make a decision.
>
> Well, I don't have any particular objection to adding pg_ prefixes
> as alternate names for the existing scripts. However, it's not clear
> what is the point unless we have the intention to remove the old names
> at some time in the foreseeable future. And the consensus of the
> previous thread on -patches seemed to be that nobody except Zdenek
> was very eager to do that.

Yeah, I have to had two reason for this patch. First is my personal, because I
don't like these names since 1999. And second is that Solaris architects do not
like these names. Especially createdb and createuser. It could clash with some
system utility.

> In any case, there is no value in discussing this further on -patches
> since the readers of this list already weighed in. If you want to
> make a decision then it needs to be made on -hackers or -general.

I think both are important (maybe general is more important). Maybe we can put
also a survey on webpage.

On other side. The question is also if we really still need these utilities? If
you look on them there are missing features. E.g vacuumdb does not allow make
VACUUM FREEZ or set some modern version of vacuum parameters. There is not
createtablespace command and so on...

Zdenek

On Mon, Mar 24, 2008 at 09:19:42PM +0100, Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Bruce Momjian <bruce(at)momjian(dot)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
>>
>>> I think we need to make a decision.
>>
>> Well, I don't have any particular objection to adding pg_ prefixes
>> as alternate names for the existing scripts. However, it's not
>> clear what is the point unless we have the intention to remove the
>> old names at some time in the foreseeable future. And the
>> consensus of the previous thread on -patches seemed to be that
>> nobody except Zdenek was very eager to do that.
>
> Yeah, I have to had two reason for this patch. First is my personal,
> because I don't like these names since 1999. And second is that
> Solaris architects do not like these names. Especially createdb and
> createuser. It could clash with some system utility.

+1 for renaming the utilities. Not stomping on the global namespace
is one place where MySQL is really out ahead of us.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Mar 2008 14:12:19 -0700
David Fetter <david(at)fetter(dot)org> wrote:

> > Yeah, I have to had two reason for this patch. First is my personal,
> > because I don't like these names since 1999. And second is that
> > Solaris architects do not like these names. Especially createdb and
> > createuser. It could clash with some system utility.
>
> +1 for renaming the utilities. Not stomping on the global namespace
> is one place where MySQL is really out ahead of us.

- -1 I have not yet seen an argument that has compelled me to actually
want to have us enter the Gnome world of binary naming.

However, if we *must* go down this route let us please use pgcreatedb
*not* pg_createdb.

Sincerely,

Joshua D. Drake

- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH6BohATb/zqfZUUQRAjm5AJ0QFb1C5/BaAIMjnu/OdqTsCO/1EACfX3XL
PNC+b1WIXd1fgJz23e9Gles=
=UkoA
-----END PGP SIGNATURE-----

Which part of "this is the wrong list" wasn't clear to you guys?

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Mar 2008 18:30:46 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Which part of "this is the wrong list" wasn't clear to you guys?

I actually didn't even notice. Sorry Tom.

Joshua D. Drake

- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH6C1YATb/zqfZUUQRAlenAJwIBnHS0rWIyx2gE/lbeHWEmeGVgACbB/1/
HmcDiHcVbe5zhJcXW8oir1g=
=KS1F
-----END PGP SIGNATURE-----

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(dot)8050102(at)sun(dot)com(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)hub(dot)org MSN . scrappy(at)hub(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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(dot)Kotala(at)Sun(dot)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(dot)Kotala(at)Sun(dot)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(dot)Kotala(at)Sun(dot)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(dot)Kotala(at)Sun(dot)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(at)hub(dot)org MSN . scrappy(at)hub(dot)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(at)hub(dot)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(dot)Kotala(at)Sun(dot)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(dot)Kotala(at)Sun(dot)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

FYI, the patch author and survey requestor has withdrawn the patch with
the following comment:

> I think we can reject this patch. I don't process yet output from survey
> on general, but it seems that more users prefer pg_ prefix, but idea of
> "pgc" command seems to be better. I think it is good idea for 9.0 release.

The TODO item has been removed as well:

* Prefix command-line utilities like createuser with 'pg_'

http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php

---------------------------------------------------------------------------

Zdenek Kotala wrote:
> Tom Lane napsal(a):
> > Bruce Momjian <bruce(at)momjian(dot)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
> >
> >> I think we need to make a decision.
> >
> > Well, I don't have any particular objection to adding pg_ prefixes
> > as alternate names for the existing scripts. However, it's not clear
> > what is the point unless we have the intention to remove the old names
> > at some time in the foreseeable future. And the consensus of the
> > previous thread on -patches seemed to be that nobody except Zdenek
> > was very eager to do that.
>
> Yeah, I have to had two reason for this patch. First is my personal, because I
> don't like these names since 1999. And second is that Solaris architects do not
> like these names. Especially createdb and createuser. It could clash with some
> system utility.
>
> > In any case, there is no value in discussing this further on -patches
> > since the readers of this list already weighed in. If you want to
> > make a decision then it needs to be made on -hackers or -general.
>
> I think both are important (maybe general is more important). Maybe we can put
> also a survey on webpage.
>
> On other side. The question is also if we really still need these utilities? If
> you look on them there are missing features. E.g vacuumdb does not allow make
> VACUUM FREEZ or set some modern version of vacuum parameters. There is not
> createtablespace command and so on...
>
> Zdenek

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +