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