Renaming some binaries

On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote:

Hi,

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'.

+1 for pg_ . We should have done this long ago, but this is better
fixed than left broken.

If we have a consensus
about this change, I suggest renaming the following binaries:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
initdb
oid2name
reindexdb
vacuumdb
vacuumlo

Another major change related to this topic is assemble functionalities
from binaries. We currently have 34 binaries (is that a lot for a single
software?). Also, some of them have the same principle: execute a
administrative or maintenance command. IMHO, from the list above, we
could reduce it to:

pg_command: clusterdb, createdb, dropdb, createuser, dropuser,
createlang, droplang, reindexdb, vacuumdb, vacuumlo. It also has the
advantage to allow adding new administrative/maintenance commands to it
in the future;

Would these make sense as pg_ctl options, or are you separating them
out because they're not instance-wide? If separating them is
important on those grounds, how about something like pg_db or
pg_db_command?

pg_oid2name: I don't have a strong opinion that it fits in pg_command;

I vaguely knew that this existed, but I can't recall having heard of
anybody actually using it. I suppose it's under pg_ctl if the split
above between instance-wide and db-specific holds.

initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.

Opinions?

+1 for removing initdb.

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

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

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

On 26-08-2016 14:03, David Fetter wrote:

Would these make sense as pg_ctl options, or are you separating them
out because they're not instance-wide? If separating them is
important on those grounds, how about something like pg_db or
pg_db_command?

It doesn't make sense because pg_ctl is server-side and pg_command would
be client-side.

pg_oid2name: I don't have a strong opinion that it fits in pg_command;

I vaguely knew that this existed, but I can't recall having heard of
anybody actually using it. I suppose it's under pg_ctl if the split
above between instance-wide and db-specific holds.

I don't use it for a long time. It also a client-side binary then better
place for it is pg_command. BTW, is anybody using it? If so, we could
add this functionality to psql and remove it.

--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

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

On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote:

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus
about this change, I suggest renaming the following binaries:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
initdb
oid2name
reindexdb
vacuumdb
vacuumlo

Why not just remove them all and change the docs to suggest using

psql -c "CREATE DATABASE foo"
etc

Less code, no confusion because we have just one client tool - psql.

Almost all serious users will be issuing more than one DDL command at
a time, so they'll be writing a script anyway.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On 2016-08-26 22:01:58 +0200, Simon Riggs wrote:

On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote:

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus
about this change, I suggest renaming the following binaries:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
initdb
oid2name
reindexdb
vacuumdb
vacuumlo

Why not just remove them all and change the docs to suggest using

psql -c "CREATE DATABASE foo"
etc

Less code, no confusion because we have just one client tool - psql.

Several of them have the ability to connect to several databases, some
even do that in parallel.

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

On 2016-08-26 15:03, Andres Freund wrote:

On 2016-08-26 22:01:58 +0200, Simon Riggs wrote:

On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br>
wrote:

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus
about this change, I suggest renaming the following binaries:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
initdb
oid2name
reindexdb
vacuumdb
vacuumlo

Why not just remove them all and change the docs to suggest using

psql -c "CREATE DATABASE foo"
etc

Less code, no confusion because we have just one client tool - psql.

Several of them have the ability to connect to several databases, some
even do that in parallel.

vacuumdb being one that I've needed recently to do a number of DB's in a
row.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

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

Simon Riggs wrote:

On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote:

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus
about this change, I suggest renaming the following binaries:

Why not just remove them all and change the docs to suggest using

psql -c "CREATE DATABASE foo"

I agree that some of these commands are redundant, and that we seem to
have them just because we can, not because they provide useful
functionality:
createdb createlang createuser dropdb droplang dropuser

I would rather have a single command that can do all those actions.
We could have things like
pg_ctl createuser

I agree with Simon that many "serious users" would not be using
the shell to implement this functionality, but something higher-level (a
GUI, some web app) that's going to go through SQL instead. Still, for
ad-hoc admin tasks it seems convenient to have the shell interface.

Nowadays git and many other programs have a model where a single command
(git) can call a number of different binaries which are not in PATH
(/usr/lib/git-core in my installation). We could do something similar,
where little else apart from pg_ctl, pg_dump, pgbench are in path, and
most binaries are in some hidden binary directory known to pg_ctl.

pg_ctl vacuum -j4 <database>

(Personally, I very often have postmaster running on its own terminal
with output to stderr. It'd be a little sad to lose that functionality,
but what value does it offer to regular users? I can script my way
around its lack, if needed.)

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On 08/26/2016 07:03 PM, David Fetter wrote:

On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote:

Hi,

...

initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.

Opinions?

+1 for removing initdb.

We can't just remove it because pg_ctl actually calls initdb, so we
would have to move the code from src/bin/initdb to src/bin/pg_ctl. Which
is doable, but I assume we'd also change how we pass parameters to it -
right now we have to do this:

pg_ctl init -o "... initdb params ..."

But I assume we'd change this to regular parameters, if 'init' gets
merged into pg_ctl - otherwise we'd force users to construct the param
string only to immediately parse it (currently the "system()" call does
that for us, but we'd have to implement that in pg_ctl).

That however means that not only we break the scripts for all those
calling initdb directly (and there's quite a few of them, I'm sure,
exactly because it's simpler to pass the parameters directly), but also
for all those already using pg_ctl.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On Fri, Aug 26, 2016 at 04:33:47PM -0300, Euler Taveira wrote:

On 26-08-2016 14:03, David Fetter wrote:

Would these make sense as pg_ctl options, or are you separating them
out because they're not instance-wide? If separating them is
important on those grounds, how about something like pg_db or
pg_db_command?

It doesn't make sense because pg_ctl is server-side and pg_command would
be client-side.

Perfect!

pg_oid2name: I don't have a strong opinion that it fits in pg_command;

I vaguely knew that this existed, but I can't recall having heard of
anybody actually using it. I suppose it's under pg_ctl if the split
above between instance-wide and db-specific holds.

I don't use it for a long time. It also a client-side binary then better
place for it is pg_command. BTW, is anybody using it? If so, we could
add this functionality to psql and remove it.

Sure. For server versions 10 or better, it could be a call to a new
server-side function.

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

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

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

On 2016-08-26 13:26:39 -0300, Euler Taveira wrote:

I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus
about this change, I suggest renaming the following binaries:

clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
initdb
oid2name
reindexdb
vacuumdb
vacuumlo

Uhm, that'd need a careful backward compatibility plan, including a period of
supporting both names.

Another major change related to this topic is assemble functionalities
from binaries. We currently have 34 binaries

(is that a lot for a single software?).

Does it matter? The few bytes of disk space are essentially irrelevant.

That said, on the code level, there'd be considerable benefit of coalescing:

pg_command: clusterdb, createdb, dropdb, createuser, dropuser,
createlang, droplang, reindexdb, vacuumdb, vacuumlo.

these commands. We could do the old trick of leaving the old names as in
place as symlinks.

initdb: we already have 'pg_ctl init' (since 9.0) and could remove
initdb.

I fairly strongly against removing initdb as a separate binary. Issuies
during cluster creation are already annoying to debug.

This is a *significant* amount of work, it'll make backpatching a
nightmare (although not that much happens in these binaries). I
personally see better uses of my time.

Andres

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

On 8/26/16 12:26 PM, Euler Taveira wrote:

initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.

I have a concern specifically about pg_ctl. Depending on how your
PostgreSQL is packaged, not all of the pg_ctl actions are safe or
sensible to run. For example, if you are using systemd, then using
pg_ctl restart will probably not do the right thing. And depending on
SELinux (maybe), running initdb directly might also not do the right
thing. In most cases, you can just not use pg_ctl and do all these
things differently, but for example pg_ctl promote is the only
documented way to do that thing.

Until we have a better way to figure that out, I wouldn't want to put
more things into pg_ctl, especially as the only way.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On Fri, Aug 26, 2016 at 5:42 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:

On 8/26/16 12:26 PM, Euler Taveira wrote:

initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.

I have a concern specifically about pg_ctl. Depending on how your
PostgreSQL is packaged, not all of the pg_ctl actions are safe or
sensible to run. For example, if you are using systemd, then using
pg_ctl restart will probably not do the right thing. And depending on
SELinux (maybe), running initdb directly might also not do the right
thing. In most cases, you can just not use pg_ctl and do all these
things differently, but for example pg_ctl promote is the only
documented way to do that thing.

Until we have a better way to figure that out, I wouldn't want to put
more things into pg_ctl, especially as the only way.

+1. Actually, my reasons for not wanting to put more stuff into
pg_ctl are mostly different from yours, but I endorse the conclusion,
at least. I think that it's just not going to be convenient. initdb
is a complicated command with a bunch of options that are mostly all
different from the options to pg_ctl. If we merge the two, then
either pg_ctl has to be able to parse the initdb options and pass them
through, or else you have to have some other convention for passing
arguments through to initdb, like pg_ctl init -o "-X /ssd/foo" which
is really not that much fun to remember or type, especially if the
path has spaces in it and thus requires some kind of nested quoting.

I do think it would make sense to add "pg_" to the beginning of all of
most or all of the command names. And I do think it would make sense
to just get rid of the scripts that don't do anything more than run a
single command via psql. Binaries that offer additional functionality
we might as well keep.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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