script binaries renaming

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.Kotala@Sun.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.Kotala@Sun.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.Kotala@Sun.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@seespotcode.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.Kotala@Sun.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.Kotala@Sun.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.Kotala@Sun.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