On Fri, Aug 26, 2016 at 5:42 PM, Peter Eisentraut <peter.eisentr...@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