Thread: Survey: renaming/removing script binaries (createdb, createuser...)

Hello All,

I prepared patch for renaming postgreSQL script tools like createdb, createuser,
etc. to pg_createdb, pg_creteuser. Original names will be kept for 2 or 3
following versions. The main reason for the patch is to avoid possible clash of
names with systems tools.

And after long discussion on patches and hackers list we have made a decision
than we need input from wide audience. This is a reason why I prepare following
surveys.

See:
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php


Please let us know your meaning,

        thanks Zdenek Kotala


1) What type of names do you prefer?
-------------------------------

a) old notation - createdb, createuser ...
b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
c) new one with pg prefix - pgcreatedb, pgcreateuser ...
d) remove them - psql is the solution
e) remove them - pgadmin is the solution


2) How often do you use these tools?
-----------------------------------

a) every day (e.g. in my cron)
b) one per week
c) one time
d) never


3) What name of initdb do you prefer?
---------- --------------------------

a) initdb
b) pg_initdb
c) pg_init
d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
e) What is initdb? My start/stop script does it automatically.

4) How do you perform VACUUM?
-----------------------------

a) vacuumdb - shell command
b) VACUUM - SQL command
c) autovacuum
d) What is vacuum?

>
> Please let us know your meaning,
>
>         thanks Zdenek Kotala
>

1. c
2. a
3. other = "pginitdb", to be consistent with pgcreatedb,etc
4. a

Zdeněk Kotala wrote:
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution

B

> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

B

> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.

B

> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?

B & C

Colin

Zdeněk Kotala escribió:
> Hello All,
>
> I prepared patch for renaming postgreSQL script tools like createdb,
> createuser, etc. to pg_createdb, pg_creteuser. Original names will be
> kept for 2 or 3 following versions. The main reason for the patch is
> to avoid possible clash of names with systems tools.
>
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why I
> prepare following surveys.
>

1) b
2) a
3) b
4) a and c

1) b
2) c
3) d
4) b & c

--
Mailed by:
UnReAl4U - unreal4u
ICQ #: 54472056
www: http://www.chilehardware.com/

On Wed, 26 Mar 2008 15:25:04 +0100
Zdeněk Kotala <Zdenek.Kotala@Sun.COM> wrote:

> Please let us know your meaning,

I hope it is the right place where to post.

> 1) What type of names do you prefer?
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...

I'd like the idea of having one command + action as in
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
and yeah I read the follow-up and Tom's comments on psql -c
but still
- maybe a pg[something] action may be better integrated with
bash auto-completion without rewriting a sql parser
- you could still have man pg[something]
- it may simplify inputting passwords
- it separates admin tasks from "sql coding"

> 2) How often do you use these tools?

> a) every day (e.g. in my cron)

> 3) What name of initdb do you prefer?

> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new
> functionality)

+ someone on the list pointed out consistency with 1)

AND ;)

> e) What is initdb? My start/stop script does it
> automatically.

> 4) How do you perform VACUUM?

> c) autovacuum

my 0.2 €

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

1. b
2. b
3. b
4. c

---------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
---------------------------------------------------------------

1.  b
2.  c
3.  d
4.  b and c

I do most of my admin using SQL these days. my preference would be
towards keeping them because they're nice in the beginning.


  Sam

> 1) What type of names do you prefer?
> -------------------------------

a.

> 2) How often do you use these tools?
> -----------------------------------

b.

> 3) What name of initdb do you prefer?
> ---------- --------------------------

d.

> 4) How do you perform VACUUM?
> -----------------------------

a + b + c.
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA.  here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)

1.) b
2.) a
3.) b
4.) a+c

On Wed, 26 Mar 2008 15:25:04 +0100 Zden__k Kotala <Zdenek.Kotala@Sun.COM> thought long, then sat down and wrote:

> Hello All,
> 
> I prepared patch for renaming postgreSQL script tools like createdb, createuser, 
> etc. to pg_createdb, pg_creteuser. Original names will be kept for 2 or 3 
> following versions. The main reason for the patch is to avoid possible clash of 
> names with systems tools.
> 
> And after long discussion on patches and hackers list we have made a decision 
> than we need input from wide audience. This is a reason why I prepare following 
> surveys.
> 
> See:
> http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php
> 
> 
> Please let us know your meaning,
> 
>         thanks Zdenek Kotala
> 
> 
> 1) What type of names do you prefer?
> -------------------------------
> 
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution
> 
> 
> 2) How often do you use these tools?
> -----------------------------------
> 
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never
> 
> 
> 3) What name of initdb do you prefer?
> ---------- --------------------------
> 
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.
> 
> 4) How do you perform VACUUM?
> -----------------------------
> 
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?
> 
> 
> 
> 
> 
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


-- 
Frank Finner

Invenius - Lösungen mit Linux
Köpfchenstraße 36
57072 Siegen
Telefon: 0271 231 8606    Mail: frank.finner@invenius.de
Telefax: 0271 231 8608    Web:  http://www.invenius.de
Key fingerprint = 90DF FF40 582E 6D6B BADF  6E6A A74E 67E4 E788 2651

Zdeněk Kotala <Zdenek.Kotala@Sun.COM> writes:

> 1) What type of names do you prefer?
>
> d) remove them - psql is the solution
>
>
> 2) How often do you use these tools?
>
> d) never
>
>
> 3) What name of initdb do you prefer?
>
> a) initdb
>
>
> 4) How do you perform VACUUM?
>
> b) VACUUM - SQL command


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

> 1) What type of names do you prefer?
> d) remove them - psql is the solution
>
> 2) How often do you use these tools?
> a) every day (e.g. in my cron)

> 3) What name of initdb do you prefer?
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)

> 4) How do you perform VACUUM?
> a) vacuumdb - shell command

I like the idea of fewer tools.
Will change to do VACUUM from psql instead
/Björn Lundin

> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution

b

> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

b

> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new
> functionality)
> e) What is initdb? My start/stop script does it automatically.

d

> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?

c

--
Diogo Biazus
diogo@softa.com.br
http://www.softa.com.br
http://www.postgresql.org.br

On Mar 26, 2008, at 9:37 AM, björn lundin wrote:
>> 1) What type of names do you prefer?
>> d) remove them - psql is the solution
>>
>> 2) How often do you use these tools?
>> a) every day (e.g. in my cron)
>
>> 3) What name of initdb do you prefer?
>> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new
>> functionality)
>
>> 4) How do you perform VACUUM?
>> a) vacuumdb - shell command
>
> I like the idea of fewer tools.
> Will change to do VACUUM from psql instead

What's the psql equivalent of the "standard" use case of "vacuumdb -a"?
(If you don't know the answer, for both unix and windows, you don't get
to vote for removing vacuumdb).

Cheers,
   Steve

At 10:25a -0400 on Wed, 26 Mar 2008, Zdeněk Kotala wrote:
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why
> I prepare following surveys.

1. b
2. b
3. b (but whichever, just be consistent)
4. b & c

I don't care, really.  The value of pg_* is that it'd obvious it's
Postgres related, it'd be consistent with at least two other APIs I
already know, it'd be easy for noobs to find with "pg_<tab><tab>", and
leaves room in a cooperative sense with other DBs that might eventually
want to do something similar.

That said I'm with Sam Mason: it's a wash if I use SQL or them.
However, they're very nice for beginners, and getting beginners to
start with a project is 3/4ths the battle in'nit?

Kevin

On Mar 26, 2008, at 7:25 AM, Zdeněk Kotala wrote:
> Hello All,
>
> I prepared patch for renaming postgreSQL script tools like createdb,
> createuser, etc. to pg_createdb, pg_creteuser. Original names will
> be kept for 2 or 3 following versions. The main reason for the patch
> is to avoid possible clash of names with systems tools.

There are no existing clashes with system tools that I'm aware of. Are
there any? Most of the clashes are with other installations of
postgresql installed on the same machine, so if name clashes is the
real reason for the change, then the version number or port number of
the installation should be part of the command name - pg_8.3.1_psql,
and so on.

The normal way of dealing with multiple installations and name clashes
would be to set your shell path appropriately, though, surely? It's a
more normal way of dealing with that than renaming the actual binaries.

If, on the other hand, the main reason behind name changes were to
make the naming more intuitive for new users then changing the names
to something more appropriate might be useful. Perhaps something like
changing "postmaster" to "postgresqld", "pg_ctl" to
"safe_postgresqld", change "psql" to "postgresql", replace "createuser
-s monty" with "postgresql --user=root", followed by  "GRANT ALL
PRIVILEGES ON *.* TO 'monty'@'localhost';" and so on.

Cheers,
   Steve

>
>
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why
> I prepare following surveys.
>
> See:
> http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php
>
>
> Please let us know your meaning,
>
>         thanks Zdenek Kotala
>
>
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution
>
>
> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never
>
>
> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new
> functionality)
> e) What is initdb? My start/stop script does it automatically.
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?
>
>
>
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On Wednesday 26 March 2008, Zdeněk Kotala <Zdenek.Kotala@sun.com> wrote:
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution

c

Actually, I like a) because I'm used to them and they're in a lot of
scripts, but I can see advantages to making them look pg-specific.

> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

a

> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.

b

See notes on #1 though.

>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?

c,a,b

--
Alan

At 11:04a -0400 on Wed, 26 Mar 2008, Ivan Sergio Borgonovo wrote:
> - maybe a pg[something] action may be better integrated with
> bash auto-completion without rewriting a sql parser

$ cat ~/.hypothetical_bashrc
  ...
complete -o default -F postgres_completion_function pg_cmd
  ...

$ pg_cmd<tab><tab>
CREATE ALTER VACUUM ...

$ pg_cmd create<tab><tab>
DATABASE LANGUAGE USER

Because it'd rely on a bash function installed somewhere in the
user's session, it'd be perhaps not as universal as an installed binary.
However, on a case-by-case basis, this can certainly work.

Kevin

On Wed, 26 Mar 2008, Zdenk Kotala wrote:

> 1) What type of names do you prefer?
> -------------------------------
>
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
>
>
> 2) How often do you use these tools?
> -----------------------------------
>
> b) one per week
>
>
> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> b) pg_initdb
>
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> b) VACUUM - SQL command
> c) autovacuum

Steve Atkins wrote:

> There are no existing clashes with system tools that I'm aware of. Are
> there any? Most of the clashes are with other installations of
> postgresql installed on the same machine, so if name clashes is the real
> reason for the change, then the version number or port number of the
> installation should be part of the command name - pg_8.3.1_psql, and so
> on.

Eeek!

If we really want to go down that route, I would suggest that psql needs
to become a bridge program that calls another program in
$PREFIX/share/libexec.  So 8.3 installs share/libexec/psql-8.3 and 8.2
installs share/libexec/psql-8.2.  So bin/psql gets the server version
and then execv() the appropriate executable from share/libexec.

I "strongly object" to the idea of renaming the main binary to add a
version number to the name.

> The normal way of dealing with multiple installations and name clashes
> would be to set your shell path appropriately, though, surely? It's a
> more normal way of dealing with that than renaming the actual binaries.

That's what I do, for one.  Not necessarily the best design, but it's
easy to do.

> Perhaps something like  changing "postmaster" to "postgresqld",

It is already called "postgres" on newer versions.

> "pg_ctl" to "safe_postgresqld",

Now that's plain weird.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Zdeněk Kotala wrote:

> 1) What type of names do you prefer?

I'd prefer a "pg" program that took as arguments
the command.  So you'd have "pg createdb" instead
of "pg_createdb".

There are many precedents. "cvs update", "git pull"
"apt-get install".

Anyone else like this approach?

Of the choices, though, I prefer (d).


> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

About monthly.  I guess (b) is closest.


> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.

pg initdb

Of the choices, though, I guess (d).


> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?

(c) on most databases
(b) on certain databases

On 26/03/2008, Zdeněk Kotala <Zdenek.Kotala@sun.com> wrote:
> Hello All,
>
>  I prepared patch for renaming postgreSQL script tools like createdb, createuser,
>  etc. to pg_createdb, pg_creteuser. Original names will be kept for 2 or 3
>  following versions. The main reason for the patch is to avoid possible clash of
>  names with systems tools.
>
>  And after long discussion on patches and hackers list we have made a decision
>  than we need input from wide audience. This is a reason why I prepare following
>  surveys.
>
>  See:
>  http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
>  http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php
>
>
>  Please let us know your meaning,
>
>                 thanks Zdenek Kotala
>
>
>  1) What type of names do you prefer?
>  -------------------------------
>
>  a) old notation - createdb, createuser ...
>  b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
>  c) new one with pg prefix - pgcreatedb, pgcreateuser ...
>  d) remove them - psql is the solution
>  e) remove them - pgadmin is the solution
>

b)

>
>  2) How often do you use these tools?
>  -----------------------------------
>
>  a) every day (e.g. in my cron)
>  b) one per week
>  c) one time
>  d) never
>
>

a)

>  3) What name of initdb do you prefer?
>  ---------- --------------------------
>
>  a) initdb
>  b) pg_initdb
>  c) pg_init
>  d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
>  e) What is initdb? My start/stop script does it automatically.

b)

>
>  4) How do you perform VACUUM?
>  -----------------------------
>
>  a) vacuumdb - shell command
>  b) VACUUM - SQL command
>  c) autovacuum
>  d) What is vacuum?
>
>

a)

>
>
>
>
>
>
>  --
>  Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>  To make changes to your subscription:
>  http://www.postgresql.org/mailpref/pgsql-general
>

On Mar 26, 2008, at 10:46 AM, Alvaro Herrera wrote:
> Steve Atkins wrote:
>
>> There are no existing clashes with system tools that I'm aware of.
>> Are
>> there any? Most of the clashes are with other installations of
>> postgresql installed on the same machine, so if name clashes is the
>> real
>> reason for the change, then the version number or port number of the
>> installation should be part of the command name - pg_8.3.1_psql,
>> and so
>> on.
>
> Eeek!

These were mostly rhetorical suggestions. Not serious in themselves,
but hoping to make people come clean about why name changes of
binaries might be needed.

>
>
> If we really want to go down that route, I would suggest that psql
> needs
> to become a bridge program that calls another program in
> $PREFIX/share/libexec.  So 8.3 installs share/libexec/psql-8.3 and 8.2
> installs share/libexec/psql-8.2.  So bin/psql gets the server version
> and then execv() the appropriate executable from share/libexec.
>
> I "strongly object" to the idea of renaming the main binary to add a
> version number to the name.
>
>> The normal way of dealing with multiple installations and name
>> clashes
>> would be to set your shell path appropriately, though, surely? It's a
>> more normal way of dealing with that than renaming the actual
>> binaries.
>
> That's what I do, for one.  Not necessarily the best design, but it's
> easy to do.

Me too. And, given that, I don't see that hypothetical clashes with
potential
future system utilities (the assumption this survey thread is based
on) is a
particularly strong reason for renaming binaries.

>
>
>> Perhaps something like  changing "postmaster" to "postgresqld",
>
> It is already called "postgres" on newer versions.
>
>> "pg_ctl" to "safe_postgresqld",
>
> Now that's plain weird.

Yes, it is. But if the goal is to make it more approachable for people
who
are familiar with mysql, but not prepared to read postgresql
documentation
it's also the obvious change to make.

Cheers,
   Steve

On Wed, 26 Mar 2008 11:09:48 -0700
Steve Atkins <steve@blighty.com> wrote:

> Yes, it is. But if the goal is to make it more approachable for
> people who
> are familiar with mysql, but not prepared to read postgresql
> documentation
> it's also the obvious change to make.

I would note that system utilities can be renamed at the packagers
behest.

./configure --exec-prefix=pg

Yes this would create pgpg_ctl.

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

On Wednesday 26. March 2008, Ron Mayer wrote:

>I'd prefer a "pg" program that took as arguments
>the command.  So you'd have "pg createdb" instead
>of "pg_createdb".
>
>There are many precedents. "cvs update", "git pull"
>"apt-get install".
>
>Anyone else like this approach?

I'll second that. It would be much easier on the brain, as you might
issue a "pg --help" if you don't remember the exact syntax or even the
name of each command.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

On Wed, 26 Mar 2008, Zdeněk Kotala <Zdenek.Kotala@Sun.COM> writes:
> 1) What type of names do you prefer?
> -------------------------------
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...

OTOH,

> d) remove them - psql is the solution

> 2) How often do you use these tools?
> -----------------------------------
> d) never

I tend to call these functions within psql.

> 3) What name of initdb do you prefer?
> ---------- --------------------------
> c) pg_init

> 4) How do you perform VACUUM?
> -----------------------------
> b) VACUUM - SQL command
> c) autovacuum


Regards.

1. b
2. a
3. b (must be consistent with 1st question prefix)
4. c, b

Bruno Lavoie

Zdeněk Kotala a écrit :
> Hello All,
>
> I prepared patch for renaming postgreSQL script tools like createdb,
> createuser, etc. to pg_createdb, pg_creteuser. Original names will be
> kept for 2 or 3 following versions. The main reason for the patch is
> to avoid possible clash of names with systems tools.
>
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why I
> prepare following surveys.
>
> See:
> http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php
>
>
> Please let us know your meaning,
>
>         thanks Zdenek Kotala
>
>
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution
>
>
> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never
>
>
> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?
>
>
>
>
>
>
>

Steve Atkins <steve@blighty.com> writes:
> On Mar 26, 2008, at 10:46 AM, Alvaro Herrera wrote:
>> Steve Atkins wrote:
>>> "pg_ctl" to "safe_postgresqld",
>>
>> Now that's plain weird.

> Yes, it is. But if the goal is to make it more approachable for people
> who are familiar with mysql, but not prepared to read postgresql
> documentation it's also the obvious change to make.

If pg_ctl actually had any functional correspondence to safe_mysqld,
then maybe that would be a sane suggestion.  But it doesn't.

            regards, tom lane

Alvaro Herrera wrote:
> Steve Atkins wrote:
>
>> There are no existing clashes with system tools that I'm aware of. Are
>> there any? Most of the clashes are with other installations of
>> postgresql installed on the same machine, so if name clashes is the real
>> reason for the change, then the version number or port number of the
>> installation should be part of the command name - pg_8.3.1_psql, and so
>> on.
>
> Eeek!
>
> If we really want to go down that route, I would suggest that psql needs
> to become a bridge program that calls another program in
> $PREFIX/share/libexec.  So 8.3 installs share/libexec/psql-8.3 and 8.2
> installs share/libexec/psql-8.2.  So bin/psql gets the server version
> and then execv() the appropriate executable from share/libexec.
>

I would say if we went this way adding the version to the end could work.

I would install pg_psql_8.3.1 as well as ln -s pg_psql_8.3.1 pg_psql

This can allow more than one binary to be installed in the same base dir
and as far as shell command completion goes you can use the last version
installed by default or add a version to the end if desired.



I do think that one main bridge program could be a good way to go.
Leave the current named progs in place for a few versions though. Or
have them as a config option.



--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

On Mar 26, 2008, at 12:06 PM, Tom Lane wrote:
> Steve Atkins <steve@blighty.com> writes:
>> On Mar 26, 2008, at 10:46 AM, Alvaro Herrera wrote:
>>> Steve Atkins wrote:
>>>> "pg_ctl" to "safe_postgresqld",
>>>
>>> Now that's plain weird.
>
>> Yes, it is. But if the goal is to make it more approachable for
>> people
>> who are familiar with mysql, but not prepared to read postgresql
>> documentation it's also the obvious change to make.
>
> If pg_ctl actually had any functional correspondence to safe_mysqld,
> then maybe that would be a sane suggestion.  But it doesn't.

They both "start the server". But, no, it's a long, long way from being
a sane suggestion.

Cheers,
   Steve

"Leif B. Kristensen" <leif@solumslekt.org> writes:
> On Wednesday 26. March 2008, Ron Mayer wrote:
>> I'd prefer a "pg" program that took as arguments
>> the command.  So you'd have "pg createdb" instead
>> of "pg_createdb".

> I'll second that. It would be much easier on the brain, as you might
> issue a "pg --help" if you don't remember the exact syntax or even the
> name of each command.

I like this too.  It'd be considerably more work than the currently
proposed patch, though, since we'd have to meld the currently
separate programs into one executable.

One fairly serious objection is that doing so would eliminate the
current distinction between client-side and server-side applications,
at least if we wanted to fold both sets into one "pg" executable.
So a client-only install would be carrying some baggage in the form
of code that's useless if the server isn't local.

If we are OK with restricting the scope of the "pg" program to
client-side functionality, then there's no problem.

            regards, tom lane

On Mar 26, 2008, at 11:44 AM, Leif B. Kristensen wrote:
> On Wednesday 26. March 2008, Ron Mayer wrote:
>
>> I'd prefer a "pg" program that took as arguments
>> the command.  So you'd have "pg createdb" instead
>> of "pg_createdb".
>>
>> There are many precedents. "cvs update", "git pull"
>> "apt-get install".
>>
>> Anyone else like this approach?
>
> I'll second that. It would be much easier on the brain, as you might
> issue a "pg --help" if you don't remember the exact syntax or even the
> name of each command.

Seems like it'd be a fair bit more work to do than a simple
rename, but the end result seems a nice clean solution.

Would it make it more difficult to do a client-only
installation if "pg" replaced both things like pg_ctl and
initdb as well as createdb and createuser, though?

Cheers,
   Steve

Tom Lane wrote:
> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>> I'd prefer a "pg" program that took as arguments
>>> the command.  So you'd have "pg createdb" instead
>>> of "pg_createdb".
>
> I like this too.  It'd be considerably more work than the currently
> proposed patch, though, since we'd have to meld the currently
> separate programs into one executable.

If it'd help make it happen, I could work on a patch as a
strawman.

> One fairly serious objection is that doing so would eliminate the
> current distinction between client-side and server-side applications,
> at least if we wanted to fold both sets into one "pg" executable.
> So a client-only install would be carrying some baggage in the form
> of code that's useless if the server isn't local.
>
> If we are OK with restricting the scope of the "pg" program to
> client-side functionality, then there's no problem.

Could it detect if the server side components aren't installed
and give a "server components aren't installed" error message
if they aren't available?    This could probably be handled
reasonably portably if the "pg" program called a separate
executable for the server functionality behind the scenes.

 From a user point of view, I think the single executable's
nice.   From an installer point of view, I think keeping
them separate is nice.  Seems both would be possible this
way, tho.

Tom Lane wrote:
> "Leif B. Kristensen" <leif@solumslekt.org> writes:
> > On Wednesday 26. March 2008, Ron Mayer wrote:
> >> I'd prefer a "pg" program that took as arguments
> >> the command.  So you'd have "pg createdb" instead
> >> of "pg_createdb".
>
> > I'll second that. It would be much easier on the brain, as you might
> > issue a "pg --help" if you don't remember the exact syntax or even the
> > name of each command.
>
> I like this too.  It'd be considerably more work than the currently
> proposed patch, though, since we'd have to meld the currently
> separate programs into one executable.

I note that we can continue to have the current executables stashed in
PREFIX/share/libexec and let the "pg" executable exec them.

> If we are OK with restricting the scope of the "pg" program to
> client-side functionality, then there's no problem.

Perhaps we can put the server-side functionality on pg_ctl.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Wednesday 26 March 2008 16:25, Zdeněk Kotala wrote:

> 1) What type of names do you prefer?
> -------------------------------

b) new one with pg_ prefix - pg_createdb, pg_creteuser ...

>
> 2) How often do you use these tools?
> -----------------------------------
>

b) one per week

>
>
> 3) What name of initdb do you prefer?
> ---------- --------------------------
>

b) pg_initdb

>
> 4) How do you perform VACUUM?
> -----------------------------
>

a) vacuumdb - shell command

c) autovacuum


--
Aarni Ruuhimäki
---
Burglars usually come in through your windows.
---

Le Wednesday 26 March 2008 15:25:04 Zdeněk Kotala, vous avez écrit :
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution

B
One thing I really liked as a newcomer to PostgreSQL, compared to MySQL, was
the ability to create users and databases from command line, like a sysadm is
used to, meaning before learning how PostgreSQL works.
Compare to GRANT ALL PRIVILEGES to USER ... WITH PASS... ; flush privileges;
which tended not to work as stated in the documentation... well, I'm somewhat
attached to those command line tools.

> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

Each time I setup a new postgresql server / service, not quite as often as B,
much more than C.

> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.

pg_createcluster

> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?

autovacuum + a cron every 30 mins on some tables that need frequent purging.

HTH,
--
dim

Tom Lane wrote:
> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>> ...a "pg" program that took as arguments
>>> the command.  So you'd have "pg createdb" instead
>>> of "pg_createdb".
>
>> I'll second that. ...
>
> I like this too.

Though I guess we might need to find a different name
if we want to go down that path.  "man pg" tells me
"browse pagewise through text files".

IMHO "postgres createdb" is still better than the
whole bunch of separate commands.

Or even "pgSQL createdb" just so people know it's
not a pre-SQL postgres database :-)

On Wed, Mar 26, 2008 at 10:02:45AM -0700, Steve Atkins wrote:
> What's the psql equivalent of the "standard" use case of "vacuumdb -a"?
> (If you don't know the answer, for both unix and windows, you don't get
> to vote for removing vacuumdb).

linux:
psql -qAt -c "select E'\\\\connect ' || datname || E'\nvacuum;' from pg_database where datallowconn" | psql

windows:
psql -qAt -c "select E'\\connect ' || datname || E'\nvacuum;' from pg_database where datallowconn" | psql

that's not actually complicated (i'm not saying it's nice, as it isn't).

depesz

--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA.  here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)

Ron Mayer napsal(a):
> Zdeněk Kotala wrote:
>
>> 1) What type of names do you prefer?
>
> I'd prefer a "pg" program that took as arguments
> the command.  So you'd have "pg createdb" instead
> of "pg_createdb".
>
> There are many precedents. "cvs update", "git pull"
> "apt-get install".
>
> Anyone else like this approach?

One of my original idea was to create pg_cmd command which will integrate all
create/drop command in one. For example

pg_cmd create database
pg_cmd list user

and so on. It is also possible solution. But we need split client commands and
server commands (initdb, pg_ctl, pg_controldata...).

        Zdenek

Tom Lane napsal(a):
> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>> I'd prefer a "pg" program that took as arguments
>>> the command.  So you'd have "pg createdb" instead
>>> of "pg_createdb".
>
>> I'll second that. It would be much easier on the brain, as you might
>> issue a "pg --help" if you don't remember the exact syntax or even the
>> name of each command.
>
> I like this too.  It'd be considerably more work than the currently
> proposed patch, though, since we'd have to meld the currently
> separate programs into one executable.
>
> One fairly serious objection is that doing so would eliminate the
> current distinction between client-side and server-side applications,
> at least if we wanted to fold both sets into one "pg" executable.
> So a client-only install would be carrying some baggage in the form
> of code that's useless if the server isn't local.
>
> If we are OK with restricting the scope of the "pg" program to
> client-side functionality, then there's no problem.

I think we can use pg (or pg_cmd) for client side and integrate initdb and other
tools into pg_ctl, as a "pg_ctl init" and so on.

        Zdenek

Ron Mayer napsal(a):
> Tom Lane wrote:
>> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>>> ...a "pg" program that took as arguments
>>>> the command.  So you'd have "pg createdb" instead
>>>> of "pg_createdb".
>>
>>> I'll second that. ...
>>
>> I like this too.
>
> Though I guess we might need to find a different name
> if we want to go down that path.  "man pg" tells me
> "browse pagewise through text files".
>
> IMHO "postgres createdb" is still better than the
> whole bunch of separate commands.
>
> Or even "pgSQL createdb" just so people know it's
> not a pre-SQL postgres database :-)

My personal preference is pg_cmd :-).

        Zdenek

Alvaro Herrera napsal(a):
> Tom Lane wrote:
>> "Leif B. Kristensen" <leif@solumslekt.org> writes:
>>> On Wednesday 26. March 2008, Ron Mayer wrote:
>>>> I'd prefer a "pg" program that took as arguments
>>>> the command.  So you'd have "pg createdb" instead
>>>> of "pg_createdb".
>>> I'll second that. It would be much easier on the brain, as you might
>>> issue a "pg --help" if you don't remember the exact syntax or even the
>>> name of each command.
>> I like this too.  It'd be considerably more work than the currently
>> proposed patch, though, since we'd have to meld the currently
>> separate programs into one executable.
>
> I note that we can continue to have the current executables stashed in
> PREFIX/share/libexec and let the "pg" executable exec them.
>
>> If we are OK with restricting the scope of the "pg" program to
>> client-side functionality, then there's no problem.
>
> Perhaps we can put the server-side functionality on pg_ctl.
>

+1
Yes, pg(.*) for client side and pg_ctl for server side.

        Zdenek

1) What type of names do you prefer?
-------------------------------
b) new one with pg_ prefix - pg_createdb, pg_creteuser ...


2) How often do you use these tools?
-----------------------------------
b) one per week


3) What name of initdb do you prefer?
---------- --------------------------
b) pg_initdb

4) How do you perform VACUUM?
-----------------------------
b) VACUUM - SQL command
c) autovacuum


Paolo Saudin




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> I like this too.  It'd be considerably more work than the currently
>> proposed patch, though, since we'd have to meld the currently
>> separate programs into one executable.

> I note that we can continue to have the current executables stashed in
> PREFIX/share/libexec and let the "pg" executable exec them.

Not share/ surely, since these are executables, but yeah.

This brings me to the idea that "pg" is a very small stupid program
that just tries to match its first argument against a filename in
PREFIX/libexec/postgresql.  If it finds a match it execs that program
with the remaining args, else it fails.  If we do it that way then the
problem of a client-only installation is solved: it merely has a smaller
population of files in PREFIX/libexec, and "pg" doesn't know the
difference.  Also the problem of optionally providing the old names just
reduces to providing links in bin/, whereas with a melded executable
we'd need still more smarts to look at how it'd been invoked.

So +2 or so for this one.

            regards, tom lane

Zdenek Kotala wrote:

> One of my original idea was to create pg_cmd command which will integrate
> all create/drop command in one. For example
>
> pg_cmd create database
> pg_cmd list user
>
> and so on.

I do like this idea, though I don't like the pg_cmd name, because it
conflicts with pg_ctl on 4 chars before presenting a useful tab
completion on the shell.  Sadly, pg is already taken so we would need to
find an alternative.

Also I would vote for less verbose names -- pg vacuumdb, etc, and not
"pg database vacuum".

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

steve@blighty.com (Steve Atkins) writes:
> There are no existing clashes with system tools that I'm aware of. Are
> there any? Most of the clashes are with other installations of
> postgresql installed on the same machine, so if name clashes is the
> real reason for the change, then the version number or port number of
> the installation should be part of the command name - pg_8.3.1_psql,
> and so on.
>
> The normal way of dealing with multiple installations and name clashes
> would be to set your shell path appropriately, though, surely? It's a
> more normal way of dealing with that than renaming the actual binaries.

pg_8.3.1_psql??  That seems pretty awful to me...

My practice is to use PATH to control this.

Debian has some "more or less idiosyncratic" tools to handle having
multiple clusters around, with pg_wrapper controlling which of these
binaries you wind up pointing to.  I keep finding that I hate that,
though I haven't gotten so mad about it that I have done anything
about it ;-).

> If, on the other hand, the main reason behind name changes were to
> make the naming more intuitive for new users then changing the names
> to something more appropriate might be useful. Perhaps something like
> changing "postmaster" to "postgresqld", "pg_ctl" to
> "safe_postgresqld", change "psql" to "postgresql", replace "createuser
> -s monty" with "postgresql --user=root", followed by  "GRANT ALL
> PRIVILEGES ON *.* TO 'monty'@'localhost';" and so on.

pg_ctl is really more like the scripts in /etc/init.d; whatever it
"ought" to be called instead, I don't think "safe_postgresqld" is
it...
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/wp.html
All ITS machines now have hardware for a new machine instruction --
PFLT    Prove Fermat's Last Theorem.
Please update your programs.

On Wed, Mar 26, 2008 at 03:25:04PM +0100, Zdeněk Kotala wrote:
> Hello All,
>
> I prepared patch for renaming postgreSQL script tools like createdb,
> createuser, etc. to pg_createdb, pg_creteuser. Original names will be kept
> for 2 or 3 following versions. The main reason for the patch is to avoid
> possible clash of names with systems tools.
>
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why I
> prepare following surveys.
>
> See:
> http://archives.postgresql.org/pgsql-hackers/2008-03/msg01006.php
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00055.php
>
>
> Please let us know your meaning,
>
>         thanks Zdenek Kotala
>
>
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...

b)

> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution
>
>
> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week

b) (approx)

> c) one time
> d) never
>
>
> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
> b) pg_initdb

b)

Hrm. I'm seeing a pattern here ;)

> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum

c)

> d) What is vacuum?

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

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

On Wed, 26 Mar 2008, Steve Atkins wrote:

> These were mostly rhetorical suggestions. Not serious in themselves,
> but hoping to make people come clean about why name changes of
> binaries might be needed.

So far I haven't seen anyone besides Zdenek gives a reason why this is
worth the trouble, and that reason has been "Sun's engineers don't like
it".  Now, that alone would be enough to make it a #1 priority if, say,
Sun had just given the PostgreSQL community a billion dollars or
something...

I know I'd be curious to hear what the actual namespace clash concerns are
here, because all this talk worrying about things like "vacuumdb" seems a
bit silly to me--I'm not feeling that one as a likely problem one day.
The create* set are the only examples that seem obviously misleading and
problematic to me.  I've had my own brain fog moments where I typed
createuser when I meant useradd, and vice-versa.

Oh, and everybody should give up on "pg" as a candidate for the universal
command, those letters have been claimed in UNIX land many years ago.
You might as well want "ls".  "pgsql" or "pgcmd" might work; "pgc" is the
shortest thing I can think of that would both make sense (as a short "pg
command") and that isn't used anywhere.

And if anybody suggests putting a "_" in something I have to type all the
time, I will stick my fingers in my ears and start yelling until they
stop.  Bad enough I have to type pg_ctl a few times every day now.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

> 1) What type of names do you prefer?
> -------------------------------
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution
a)

> 2) How often do you use these tools?
> -----------------------------------
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never
b)

> 3) What name of initdb do you prefer?
> ---------- --------------------------
> a) initdb
> b) pg_initdb
> c) pg_init
> d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
> e) What is initdb? My start/stop script does it automatically.
a)

> 4) How do you perform VACUUM?
> -----------------------------
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
> d) What is vacuum?
b)

We're not seriously thinking of changing these are we? Once a command
set has been in use for as long a time as the PG command set has, any
benefit that may be derived by new users with an aversion to
documentation reading is vastly offset by the confusion that would
result among long time users whos scripts, tools and mental mental
processes all have the old names hardcoded in.

I can't imagine how there would be a nomenclature clash, if there is,
then just take one of the tools out of the path, use symlinks or put
calling scripts in the path instead. These are suboptimal solutions,
granted, but *any* naming scheme we change to will be subject to the
possibility of naming clashes with another package with a similar name,
unless we make the binaries have long, verbose names. I don't know about
you, but I don't fancy having to type "postgresqlclient dbname" to start
a DB. I like "psql dbname".

So I ask again, we're not seriously thinking about this are we?
Regards,
- Naz.

Greg Smith wrote:

> And if anybody suggests putting a "_" in something I have to type all
> the time, I will stick my fingers in my ears and start yelling until
> they stop.  Bad enough I have to type pg_ctl a few times every day now.

+10 on hating "_"


--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

Zdeněk Kotala a écrit :
> I prepared patch for renaming postgreSQL script tools like createdb,
> createuser, etc. to pg_createdb, pg_creteuser. Original names will be
> kept for 2 or 3 following versions. The main reason for the patch is to
> avoid possible clash of names with systems tools.
>
> And after long discussion on patches and hackers list we have made a
> decision than we need input from wide audience. This is a reason why I
> prepare following surveys.
>

1 : a
2 : c
3 : a
4 : a


--
Guillaume.
  http://www.postgresqlfr.org
  http://dalibo.com

> Please let us know your meaning,
> 
> 1) What type of names do you prefer?
> -------------------------------

a) with c) as a second choice. Keep names simple.

> 2) How often do you use these tools?
> -----------------------------------

a)

> 3) What name of initdb do you prefer?
> ---------- --------------------------

a)

> 4) How do you perform VACUUM?
> -----------------------------

a)

Yours,
Laurenz Albe

On 27/03/2008, Zdeněk Kotala <Zdenek.Kotala@sun.com> wrote:
>  1) What type of names do you prefer?
>  -------------------------------
>  a) old notation - createdb, createuser ...

a)  Never seen any clashes with other tools in terms of names.
     And the old sys-admin creed: don't fix it if it ain't broken.


>  2) How often do you use these tools?
>  -----------------------------------
>  a) every day (e.g. in my cron)
>  b) one per week
>  c) one time
>  d) never

e) occasionally


>  3) What name of initdb do you prefer?
>  ---------- --------------------------
>  a) initdb
>  b) pg_initdb
>  c) pg_init
>  d) pg_ctl -d <dir> init  (replace initdb with pg_ctl new functionality)
>  e) What is initdb? My start/stop script does it automatically.

a) initdb


>  4) How do you perform VACUUM?
>  -----------------------------
>  a) vacuumdb - shell command
>  b) VACUUM - SQL command
>  c) autovacuum
>  d) What is vacuum?

c, b, a ... in this order.


Cheers,
Andrej

--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.american.edu/econ/notes/htmlmail.htm

Zdeněk Kotala pisze:
> Hello All,
> 1) What type of names do you prefer?
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
b

> 2) How often do you use these tools?
> b) one per week
b

> 3) What name of initdb do you prefer?
> c) pg_init
c

> 4) How do you perform VACUUM?
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum
c

In article <12487.1206565567@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> writes:

>> I note that we can continue to have the current executables stashed in
>> PREFIX/share/libexec and let the "pg" executable exec them.

> Not share/ surely, since these are executables, but yeah.

> This brings me to the idea that "pg" is a very small stupid program
> that just tries to match its first argument against a filename in
> PREFIX/libexec/postgresql.  If it finds a match it execs that program
> with the remaining args, else it fails.

Add an optional command-line argument for specifying an alternative
PREFIX, and the problem of multiple PostgreSQL versions on one host is
solved as well.

Greg Smith wrote:

> And if anybody suggests putting a "_" in something I have to type all the
> time, I will stick my fingers in my ears and start yelling until they
> stop.  Bad enough I have to type pg_ctl a few times every day now.

alias pgctl=pg_ctl

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Shane Ambler wrote:
> Greg Smith wrote:
>
>> And if anybody suggests putting a "_" in something I have to type all
>> the time, I will stick my fingers in my ears and start yelling until
>> they stop.  Bad enough I have to type pg_ctl a few times every day now.
>
> +10 on hating "_"

+20  if need be, I'd go with - (dash) over _ (underbar)


--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

On Thu, 27 Mar 2008, Alvaro Herrera wrote:

> Greg Smith wrote:
>> And if anybody suggests putting a "_" in something I have to type all the
>> time...
>
> alias pgctl=pg_ctl

If I were allowed to change the login profile on every system I touch I
wouldn't be typing pg_ctl at all; I'd be typing "up" and "down" like on my
laptop.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Greg Smith wrote:
>> And if anybody suggests putting a "_" in something I have to type all the
>> time, I will stick my fingers in my ears and start yelling until they
>> stop.  Bad enough I have to type pg_ctl a few times every day now.

> alias pgctl=pg_ctl

Still, if we can't have "pg" then the whole idea loses a lot of its
appeal.  I'm not excited about having to type "pgcmd createdb ...",
much less anything longer.

            regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Greg Smith wrote:
> >> And if anybody suggests putting a "_" in something I have to type all the
> >> time, I will stick my fingers in my ears and start yelling until they
> >> stop.  Bad enough I have to type pg_ctl a few times every day now.
>
> > alias pgctl=pg_ctl
>
> Still, if we can't have "pg" then the whole idea loses a lot of its
> appeal.  I'm not excited about having to type "pgcmd createdb ...",
> much less anything longer.

What about pgc?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

>  1) What type of names do you prefer?
1 b
>  2) How often do you use these tools?
2 c
>  3) What name of initdb do you prefer?
3 e (pg_createcluster by Debian), then d or b
>  4) How do you perform VACUUM?
4 c b (autovac & sql vacuum)

   Regards,
     Dawid

On Wed, Mar 26, 2008 at 6:46 PM, Ron Mayer
<rm_pg@cheapcomplexdevices.com> wrote:
> Zdeněk Kotala wrote:
>
>  > 1) What type of names do you prefer?
>
>  I'd prefer a "pg" program that took as arguments
>  the command.  So you'd have "pg createdb" instead
>  of "pg_createdb".
>
>  There are many precedents. "cvs update", "git pull"
>  "apt-get install".
>
>  Anyone else like this approach?

+10

I like "pg command" approach the best!  Clean, simple, short and powerful.

Erase my previous vote. ;)  I prefer:
pg createdb

  Regards,
     Dawid

Alvaro Herrera napsal(a):
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> Greg Smith wrote:
>>>> And if anybody suggests putting a "_" in something I have to type all the
>>>> time, I will stick my fingers in my ears and start yelling until they
>>>> stop.  Bad enough I have to type pg_ctl a few times every day now.
>>> alias pgctl=pg_ctl
>> Still, if we can't have "pg" then the whole idea loses a lot of its
>> appeal.  I'm not excited about having to type "pgcmd createdb ...",
>> much less anything longer.
>
> What about pgc?
>

And what about two commands one for create and one for drop?
It save 6 or 4 chars.

pgc db  (as create db)
pgc user
pgd db  (as drop db)
pgd user

        Zdenek

Zdenek Kotala wrote:

> And what about two commands one for create and one for drop?
> It save 6 or 4 chars.
>
> pgc db  (as create db)
> pgc user
> pgd db  (as drop db)
> pgd user

Well, there are things besides create and drop -- for example vacuum.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera napsal(a):
> Zdenek Kotala wrote:
>
>> And what about two commands one for create and one for drop?
>> It save 6 or 4 chars.
>>
>> pgc db  (as create db)
>> pgc user
>> pgd db  (as drop db)
>> pgd user
>
> Well, there are things besides create and drop -- for example vacuum.
>

Yeah, good point I forgot vacuum and reindex.

OK pgc looks good.

        Zdenek

On Thursday 27. March 2008, Alvaro Herrera wrote:
>Zdenek Kotala wrote:
>> And what about two commands one for create and one for drop?
>> It save 6 or 4 chars.
>>
>> pgc db  (as create db)
>> pgc user
>> pgd db  (as drop db)
>> pgd user
>
>Well, there are things besides create and drop -- for example vacuum.

I figure something like the more or less standard options for modern
*nixes, with short and long options like eg.

pgc -C, --createdb
pgc -a, --adduser
pgc -m, --modify
pgc -D, --dropdb

etc.

Probably the short options should be capitals for db stuff, small
letters for user stuff.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

Tom Lane napsal(a):
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> I like this too.  It'd be considerably more work than the currently
>>> proposed patch, though, since we'd have to meld the currently
>>> separate programs into one executable.
>
>> I note that we can continue to have the current executables stashed in
>> PREFIX/share/libexec and let the "pg" executable exec them.
>
> Not share/ surely, since these are executables, but yeah.
>
> This brings me to the idea that "pg" is a very small stupid program
> that just tries to match its first argument against a filename in
> PREFIX/libexec/postgresql.  If it finds a match it execs that program
> with the remaining args, else it fails.  If we do it that way then the
> problem of a client-only installation is solved: it merely has a smaller
> population of files in PREFIX/libexec, and "pg" doesn't know the
> difference.  Also the problem of optionally providing the old names just
> reduces to providing links in bin/, whereas with a melded executable
> we'd need still more smarts to look at how it'd been invoked.
>
> So +2 or so for this one.

It sounds good. Only one comments libexec is not on Solaris, but PREFIX/lib is
allowed to use for this purpose.

        Zdenek

Naz Gassiep napsal(a):

>
> We're not seriously thinking of changing these are we? Once a command
> set has been in use for as long a time as the PG command set has, any
> benefit that may be derived by new users with an aversion to
> documentation reading is vastly offset by the confusion that would
> result among long time users whos scripts, tools and mental mental
> processes all have the old names hardcoded in.

Yes, I understand your point of view, but on other side there are arguments in
discussion, that for newbies old name are terrible to use and frankly, who reads
manual before he start to use a product?

> I can't imagine how there would be a nomenclature clash, if there is,
> then just take one of the tools out of the path, use symlinks or put
> calling scripts in the path instead. These are suboptimal solutions,
> granted, but *any* naming scheme we change to will be subject to the
> possibility of naming clashes with another package with a similar name,
> unless we make the binaries have long, verbose names. I don't know about
> you, but I don't fancy having to type "postgresqlclient dbname" to start
> a DB. I like "psql dbname".

Nobody want to rename psql. Personaly, I dislike current command names for long
long time. Many times I tried create unix user by createuser command. And these
names could be potential names of system commands.

> So I ask again, we're not seriously thinking about this are we?

Yes, we are. And this is a reason why I prepare this survey, because we could
not reach a decision on the -hackers. However, it seems that we choose third
variant with new wrapper command pgc.

        Zdenek

----- Original Message -----
From: "Zdenek Kotala" <Zdenek.Kotala@Sun.COM>
To: "Naz Gassiep" <naz@mira.net>
Cc: "PostgreSQL" <pgsql-general@postgresql.org>
Sent: Thursday, March 27, 2008 4:31 PM
Subject: Re: [GENERAL] Survey: renaming/removing script binaries (createdb,
createuser...)


> Naz Gassiep napsal(a):
>
> >
> > We're not seriously thinking of changing these are we? Once a command
> > set has been in use for as long a time as the PG command set has, any
> > benefit that may be derived by new users with an aversion to
> > documentation reading is vastly offset by the confusion that would
> > result among long time users whos scripts, tools and mental mental
> > processes all have the old names hardcoded in.
>
> Yes, I understand your point of view, but on other side there are
arguments in
> discussion, that for newbies old name are terrible to use and frankly, who
reads
> manual before he start to use a product?

MG>I do and frankly anyone who buys a product without understanding how this
fits into the existing system
MG>with no doc..no wiki ..no users group..is asking for heachaches..
MG>The whole idea of OpenSource project is participate in a project in which
everyone is passionate about
MG>create intelligent doc, create a wiki and have an active users group
>
> > I can't imagine how there would be a nomenclature clash, if there is,
> > then just take one of the tools out of the path, use symlinks or put
> > calling scripts in the path instead. These are suboptimal solutions,
> > granted, but *any* naming scheme we change to will be subject to the
> > possibility of naming clashes with another package with a similar name,
> > unless we make the binaries have long, verbose names. I don't know about
> > you, but I don't fancy having to type "postgresqlclient dbname" to start
> > a DB. I like "psql dbname".
>
> Nobody want to rename psql. Personaly, I dislike current command names for
long
> long time. Many times I tried create unix user by createuser command. And
these
> names could be potential names of system commands.
>
> > So I ask again, we're not seriously thinking about this are we?
>
> Yes, we are. And this is a reason why I prepare this survey, because we
could
> not reach a decision on the -hackers. However, it seems that we choose
third
> variant with new wrapper command pgc.
>
> Zdenek
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> Yes, I understand your point of view, but on other side there
> are arguments in discussion, that for newbies old name are
> terrible to use and frankly, who reads manual before he start
> to use a product?

This is a terrible argument.

> Nobody want to rename psql. Personaly, I dislike current command
> names for long long time. Many times I tried create unix user by
> createuser command. And these names could be potential names of
> system commands.

Yours is the first time I've heard of anyone with this problem.
The useradd and adduser commands don't even start with the same
letter. If it's that confusing, you can always use an alias or a
symlink to make things more inline with what you want.

For the record, I think any renaming is a terrible idea, and a solution
in search of a problem. Any change, no matter how long it takes, will
break untold number of scripts, make us look bad, and frustrate
people, similar to the way that implicit cast removal did in 8.3, but
without the Very Good Reason to show people why we made the change.

Additionally, once we make the change, to which version do we refer to
in the docs or when answering questions? You can't safely refer to
the new commands until they've had time to percolate through as people
update their database. And considering that I still work with some 7.3
system, and plenty of 7.4 ones, that could be a long time.

*If* we're going to do this, at the very least it needs to be rolled
out as a point revision update across all versions, so we minimize the
confusion for people on older versions. We also need to keep symlinks
or some other backwards-compatibilty around for a long time, *and* make
a clean break at some future major version with lots of prior warning.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200803271839
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkfsIosACgkQvJuQZxSWSshqnQCg0s7YAnxtF6qbOEiYYBifCR2y
IYsAnRvjXCDrGaKUAFaOp88vidWYixUP
=1til
-----END PGP SIGNATURE-----

On Thu, 27 Mar 2008, Leif B. Kristensen wrote:

> I figure something like the more or less standard options for modern
> *nixes, with short and long options like eg.
> pgc -C, --createdb ...

The idea thrown out was to use something like the CVS/svn model where a
single command gets called followed by either the name of the subcommand
or a very short abbreviation for it.  Here's a first cut of how I would
translate the current names, with the things I use more given the shorter
abbreviations in cases where there's some overlap in characters:

pgc cluster
pgc createdb    cd
pgc createlang    cl
pgc createuser    cu
pgc dropdb    dd    Not sure about short versions for any drop command
pgc droplang    dl
pgc dropuser    du
pgc init    i    initdb is careful not to overwrite anything
pgc oid        o
pgc config
pgc controldata
pgc ctl        c
pgc dump    d
pgc dumpall    da
pgc resetxlog    rx    Requires data dir before it doesn anything
pgc restore    r
pgc reindexdb    ri
pgc vacuum    v
pgc vacuumlo    vl

I'd also add these two:

pgc start    (pg_ctl start)
pgc stop    (pg_ctl stop)

ecpg, pg_standby, pgbench, pltcl*, postgres, postmaster, psql seem like
they really should keep their current names.

Do not take any of the above as an endorsement of this idea; I think it's
awful to even consider messing with anything when there are so many actual
important things that time could be spent on instead.  But if someone is
going to argue for a redesign of the command names, I'd at least like to
be talking about a good remapping.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Naz Gassiep napsal(a):
>> So I ask again, we're not seriously thinking about this are we?

> Yes, we are.

Make that "Zdenek is".  The reason for this survey is that he's hoping
to gather enough ammunition to overrule the opposition.

In any case, there *will* be an option to continue to have the old
names; it'll probably even be on by default, at least for awhile.

            regards, tom lane

On Thu, Mar 27, 2008 at 11:49 PM, Greg Smith <gsmith@gregsmith.com> wrote:
> On Thu, 27 Mar 2008, Leif B. Kristensen wrote:
>
>  > I figure something like the more or less standard options for modern
>  > *nixes, with short and long options like eg.
>  > pgc -C, --createdb ...
>
>  The idea thrown out was to use something like the CVS/svn model where a
>  single command gets called followed by either the name of the subcommand
>  or a very short abbreviation for it.  Here's a first cut of how I would
>  translate the current names, with the things I use more given the shorter
>  abbreviations in cases where there's some overlap in characters:
>
>  pgc cluster
[...]

Agree, except I would prefer "pg" instead of "pgc".

Why?
When I see "pgc" I am not sure what the command is for -- it looks like
a short form for "pg create something", or maybe alias for pg_ctl, of which
I know is for starting and stopping database (and not for creating users ;)).

With "pg" I am sure that the comand is "generic to the extreme", so I don't
have to assume what does "c" stand for.  Control?  Create?  Client?  or Command.

Also its about 33% shorter. ;-)

   Regards,
     Dawid

PS: And I feel it feels more natural to say "pg createuser" than "pgc
create user",
but that's solely my "typing impression".

Dawid wrote:

[...]
>
> >  abbreviations in cases where there's some overlap in characters:
> >
> >  pgc cluster
> [...]
>
> Agree, except I would prefer "pg" instead of "pgc".
>

No can do, already taken:
"> man pg
Reformatting pg(1), please wait...
PG(1)                                              User Commands                                             PG(1)

NAME
       pg - browse pagewise through text files

SYNOPSIS
       pg [ -number ] [ -p string ] [ -cefnrs ] [ +line ] [ +/pattern/ ] [ file . . . ]

DESCRIPTION
       Pg  displays  a text file on a CRT one screenful at once.  After each page, a prompt is displayed. The user
       may then either press the newline key to view the next page or one of the keys described below.

..."

The pain of realiasing pg would be significant, I think.

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

Dawid Kuroczko escribió:
> On Thu, Mar 27, 2008 at 11:49 PM, Greg Smith <gsmith@gregsmith.com> wrote:

> >  pgc cluster
>
> Agree, except I would prefer "pg" instead of "pgc".

pg is already taken by an ancient Unix pager utility (predecessor of
more, less, etc)

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Mar 27, 2008, at 5:41 PM, Tom Lane wrote:

> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Naz Gassiep napsal(a):
>>> So I ask again, we're not seriously thinking about this are we?
>
>> Yes, we are.
>
> Make that "Zdenek is".  The reason for this survey is that he's hoping
> to gather enough ammunition to overrule the opposition.

Oh, then there should have been some options in the survey along the
lines of "things are fine how they are." I replied to the survey
assuming changes were going to be made and now all we had to do was
figure out the best way to change..... but I'd rather people spent
effort on other things to begin with.

On 28/03/2008, Dawid Kuroczko <qnex42@gmail.com> wrote:
>  Agree, except I would prefer "pg" instead of "pgc".
>
>  With "pg" I am sure that the comand is "generic to the extreme", so I don't
>  have to assume what does "c" stand for.  Control?  Create?  Client?  or Command.
>
>  Also its about 33% shorter. ;-)

And it's been taken for about 35 years by a Unix command called "page".
From its man-page.

PG(1)                            User Commands                           PG(1)



NAME
       pg - browse pagewise through text files


I really find this whole discussion quite silly;  it's about someone's
personal preference?  Don't get me wrong, I'm a lowly user when it
comes to pg, and not a member of the hacker-community.  But I've
been using postgres for a good number of years now (since v7, I think)
and have become quite accustomed to the names of the tools in
use, have never observed any clashes with other tools, and as a
Linux/Unix sys-admin type of person never had a problem with
mistaking createuser for useradd or adduser.

And I'll stick by the old maxim:  if it ain't broken, don't fix it.


>    Regards,
>
>      Dawid

Cheers,
Andrej

>  PS: And I feel it feels more natural to say "pg createuser" than "pgc
>  create user", but that's solely my "typing impression".

And it's noticeably shorter to just type createuser ;} ... which worked a
treat for many many moons.


Cheers,
Andrej

--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.american.edu/econ/notes/htmlmail.htm

Gregory Williamson wrote:
> No can do, already taken:
> "> man pg
> Reformatting pg(1), please wait...
> PG(1)                                              User
> Commands                                             PG(1)
>
> NAME
>        pg - browse pagewise through text files

Good catch.  Haven't used that in ages.

Aside: +1 to not actually changing anything, despite my previous
response to the survey for the sake of responding to the survey.  I
agree with Greg Sabino Mullane in that this is *not* a problem.

Colin

Ben <bench@silentmedia.com> writes:
> On Mar 27, 2008, at 5:41 PM, Tom Lane wrote:
>> Make that "Zdenek is".  The reason for this survey is that he's hoping
>> to gather enough ammunition to overrule the opposition.

> Oh, then there should have been some options in the survey along the
> lines of "things are fine how they are."

Oh, a bit of answer-forcing wasn't beneath him.

            regards, tom lane

> > Oh, then there should have been some options in the survey along the
> > lines of "things are fine how they are."
>
> Oh, a bit of answer-forcing wasn't beneath him.


Ummm... Isn't that what Option A is about ?


1) What type of names do you prefer?
-------------------------------
a) old notation - createdb, createuser ...
b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
c) new one with pg prefix - pgcreatedb, pgcreateuser ...
d) remove them - psql is the solution
e) remove them - pgadmin is the solution

On Mar 26, 2008, at 7:25 AM, Zdeněk Kotala wrote:
>
> 1) What type of names do you prefer?
> -------------------------------
>
> a) old notation - createdb, createuser ...
>
> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)
> b) one per week
> c) one time
> d) never

e) Multiple times an hour while I'm working. By hand and from scripts.

> 3) What name of initdb do you prefer?
> ---------- --------------------------
>
> a) initdb
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command
> c) autovacuum

e) All three of the above.

Cheers,
   Steve

On Wednesday 26 March 2008 16:03, hubert depesz lubaczewski wrote:
> On Wed, Mar 26, 2008 at 10:02:45AM -0700, Steve Atkins wrote:
> > What's the psql equivalent of the "standard" use case of "vacuumdb -a"?
> > (If you don't know the answer, for both unix and windows, you don't get
> > to vote for removing vacuumdb).
>
> linux:
> psql -qAt -c "select E'\\\\connect ' || datname || E'\nvacuum;' from
> pg_database where datallowconn" | psql
>
> windows:
> psql -qAt -c "select E'\\connect ' || datname || E'\nvacuum;' from
> pg_database where datallowconn" | psql
>
> that's not actually complicated (i'm not saying it's nice, as it isn't).
>

I have to think that a better solution for someone whose needs are met by the
above is to just enable autovacuum.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Greg Sabino Mullane napsal(a):

<snip>

>> Nobody want to rename psql. Personaly, I dislike current command
>> names for long long time. Many times I tried create unix user by
>> createuser command. And these names could be potential names of
>> system commands.
>
> Yours is the first time I've heard of anyone with this problem.
> The useradd and adduser commands don't even start with the same
> letter. If it's that confusing, you can always use an alias or a
> symlink to make things more inline with what you want.

It is not about letters but about memory :-). Currently it is not problem for
me, but it was when I was starting play with Linux.

> For the record, I think any renaming is a terrible idea, and a solution
> in search of a problem. Any change, no matter how long it takes, will
> break untold number of scripts, make us look bad, and frustrate
> people, similar to the way that implicit cast removal did in 8.3, but
> without the Very Good Reason to show people why we made the change.

I understand this point of view. And it is reason also why I asked if people use
these commands or they prefer psql. For example nobody had complained that
"createtablespace" command is missing. Does it mean that nobody uses
tablespaces? It means everybody must use psql for tablespace creation. I
personally use psql for everything.  Only sometimes  I use vacumdb or createuser
command.

Unfortunately, I not good survey maker and some tools usage statistic could be
nice to have in survey as well. :(

I have lived with current names and I can live with them in the future as well.


> Additionally, once we make the change, to which version do we refer to
> in the docs or when answering questions? You can't safely refer to
> the new commands until they've had time to percolate through as people
> update their database. And considering that I still work with some 7.3
> system, and plenty of 7.4 ones, that could be a long time.

Doc is related to version. And if you look on postmaster command in latest
documentation that it says obsolete use postgres.

> *If* we're going to do this, at the very least it needs to be rolled
> out as a point revision update across all versions, so we minimize the
> confusion for people on older versions. We also need to keep symlinks
> or some other backwards-compatibilty around for a long time, *and* make
> a clean break at some future major version with lots of prior warning.

I don't think so, that backport is necessary, but backward compatibility is
obvious for new severals releases.

By the way does postgreSQL has some EOL strategy? There are lot of OBSOLETE
thinks mentioned in documentation, but I have never seen a list/roadmap when
they will be removed.

        Zdenek

Adam Rich wrote:
> > > Oh, then there should have been some options in the survey along the
> > > lines of "things are fine how they are."
> >
> > Oh, a bit of answer-forcing wasn't beneath him.
>
>
> Ummm... Isn't that what Option A is about ?
>
>
> 1) What type of names do you prefer?
> -------------------------------
> a) old notation - createdb, createuser ...
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
> c) new one with pg prefix - pgcreatedb, pgcreateuser ...
> d) remove them - psql is the solution
> e) remove them - pgadmin is the solution

One very minimal idea that isn't listed here is just to rename
createuser to createdbuser or createpguser, with similar changes for
dropuser, createlang, and droplang.  That gives all commands a 'db' or
'pg' in part of the command, with no underscores, and it matches the
existing command that already have 'db'.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

On 2008-03-28 02:00, Andrej Ricnik-Bay wrote:
> On 28/03/2008, Dawid Kuroczko <qnex42@gmail.com> wrote:
>>  Agree, except I would prefer "pg" instead of "pgc".
>
> And it's been taken for about 35 years by a Unix command called "page".
> From its man-page.
>        pg - browse pagewise through text files

So maybe "pctl", consistent with "psql".

It is short enough, does not need "shift" and does not confuse, if man
knows that it has something to do with Postgres. It looks it is yet not
taken.

Regards
Tometzky
--
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
                                                      Winnie the Pooh

On Fri, Mar 28, 2008 at 3:41 PM, Tomasz Ostrowski
<tometzky@batory.org.pl> wrote:
> On 2008-03-28 02:00, Andrej Ricnik-Bay wrote:
>  > On 28/03/2008, Dawid Kuroczko <qnex42@gmail.com> wrote:
>  >>  Agree, except I would prefer "pg" instead of "pgc".
>  >
>
> > And it's been taken for about 35 years by a Unix command called "page".
>  > From its man-page.
>
> >        pg - browse pagewise through text files
>
>  So maybe "pctl", consistent with "psql".
>
>  It is short enough, does not need "shift" and does not confuse, if man
>  knows that it has something to do with Postgres. It looks it is yet not
>  taken.

I like it.  Personally "pctl" feels better than "pgc" :-)

   Regards,
       Dawid

Steve Atkins wrote:
> What's the psql equivalent of the "standard" use case of "vacuumdb -a"?

There isn't a good one.  A tool, possibly a psql option, to do "run this SQL
command in all databases", would allow us to get rid of clusterdb, reindexdb,
vacuumdb.

Joshua D. Drake wrote:
> I would note that system utilities can be renamed at the packagers
> behest.
>
> ./configure --exec-prefix=pg
>
> Yes this would create pgpg_ctl.

No, this would make configure abort with an error message.

On Thu, Mar 27, 2008 at 10:41:52PM -0000, Greg Sabino Mullane wrote:
>
> For the record, I think any renaming is a terrible idea, and a solution
> in search of a problem. Any change, no matter how long it takes, will
> break untold number of scripts, make us look bad, and frustrate
> people, similar to the way that implicit cast removal did in 8.3, but
> without the Very Good Reason to show people why we made the change.

I agree with everything in the above.  It would be easier for new users if
we spelled it "list files" instead of "ls", and much safer if "su -; rm -rf
/" always caused an error.  But we have to live with the world we have, not
the alternate universe contemplated in the _UNIX Haters' Handbook_.  It is
too late to change command names, even if it were a good idea.

A

Although I, too, am not fond of the current command names, I'm not aware of a naming conflict that is serious enough to warrant renaming. Do we have even one example of one significant naming conflict?

Renaming executable seems likely to create much more confusion that it will solve. I loathe the idea of confounding years of newsgroup/mailing list wisdom, especially for newcomers. The specter of having to ask questions like "Which executable naming scheme are you using?" is also unpalatable. (Remember, this is the group that will engage in multi-message threads about postgres, postgresql, PostgreSQL, PG, postgre, etc. We'll need a new list for the fallout of renaming executables.)

Perhaps one way to sidestep this issue is for you (Zdeněk) to create a pgFoundry project that provides the command line interface you propose by wrapping the existing postgresql binaries. This would provide the more rational names you seek. Furthermore, it could be used to provide the *sole* interface to postgresql if postgresql is configured with a --prefix that sequesters it from system paths. In the meritocracy of open source, your interface might become the official interface later on.

I completely "get" your motivation and I appreciate your effort to tidy up. However, renaming is going to create problems, not solve them. (And, it's not even clear that there is a problem.)

-Reece


P.S. My responses:
1. a (do nothing)  (or b if there really must be a change)
2. a (multiple times daily)
3. consistent with 1
4. c
Blue. No, red. Aaah...

-- Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0

Chris Browne wrote:
...
>
> pg_ctl is really more like the scripts in /etc/init.d; whatever it
> "ought" to be called instead, I don't think "safe_postgresqld" is
> it...

eek. where is that save_ something coming from? Apache uses
apachectl which seems pretty forward - pg_ctl seems to be in
the same spirit. Naming it pgctl could simplify typing and
making it a wrapper (similar to zopectl :-) with
start/stop/status/debug/run ... could have some benefit.

Regards
Tino

Tino Wildenhain wrote:
> Chris Browne wrote:
> ...
>>
>> pg_ctl is really more like the scripts in /etc/init.d; whatever it
>> "ought" to be called instead, I don't think "safe_postgresqld" is
>> it...
>
> eek. where is that save_ something coming from?
 From safe_mysqld , I imagine. I never understood the rationale behind
that naming myself; names like pg_ctl, apachectl, etc seem to suggest
their purpose more directly.

--
Craig Ringe

I've only been peripherally watching this thread and this may have been
mentioned...

One advantage of using a consistent prefix is that when you have
forgotten the exact name of a rarely used command and you are using a
shell with readline support, "pg_<tab><tab>" will bring up a list of
available commands.

Cheers,
Steve

On 01/04/2008, Steve Crawford <scrawford@pinpointresearch.com> wrote:
>  One advantage of using a consistent prefix is that when you have
>  forgotten the exact name of a rarely used command and you are using a
>  shell with readline support, "pg_<tab><tab>" will bring up a list of
>  available commands.
For any value of shell IN {bash, tcsh, zsh}.
sh (default on solaris) and ksh won't, and neither will cmd.exe

But I (as a user of bash) see your point.


>  Cheers,
>
> Steve
Cheers,
Andrej

--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.american.edu/econ/notes/htmlmail.htm

> 1) What type of names do you prefer?
> -------------------------------
> b) new one with pg_ prefix - pg_createdb, pg_creteuser ...
>
> 2) How often do you use these tools?
> -----------------------------------
>
> a) every day (e.g. in my cron)

> 3) What name of initdb do you prefer?
> ---------- --------------------------

> b) pg_initdb
>
> 4) How do you perform VACUUM?
> -----------------------------
>
> a) vacuumdb - shell command
> b) VACUUM - SQL command


[ Clemens Schwaighofer                      -----=====:::::~ ]
[ IT Engineer/Manager, TEQUILA\ Japan IT Group               ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp                                   ]

1. a - old notation
2. a
3. e & d
4. b & c

* F. Jovan Jester (jesterj@groupspeak.com) wrote:
> 1. a - old notation
> 2. a
> 3. e & d
> 4. b & c

*blink*

hmm.  How about 1 and 2?
(is this an April fools joke?)

    Stephen