Re: Tom Lane 2019-03-29 <19517.1553876700@sss.pgh.pa.us>
> >> Or perhaps better, allow pg_ctl to grow new subcommands for those
> >> tasks?
>
> > We'd need to be careful to somehow delineate commands that need access
> > to the data directory / run locally on the server from the ones that
> > just needs a client connection.
>
> Hmm, that's a good point: to put it in terms that make sense to a
> packager, it'd no longer be clear whether pg_ctl belongs in the
> server package or the client package.
True, and putting end-user commands like "create database" into the
same admin tool like "stop", "promote", and "kill" feels both wrong
and dangerous to me. It would also cause people to wonder why "pg_ctl
-h remotehost stop" doesn't work.
> I'm still not thrilled with wedging in these things as options
> to psql though: its command line semantics are overly complicated
> already, when you consider things like multiple -c and -f options.
> I mean, somebody might think it's a feature to be able to do
>
> psql --createuser alice --createuser bob -c 'some command' -f somefile
>
> but I don't.
Ack. (Otoh, just processing all arguments after another might be
well-defined, and not too hard?)
> Maybe if we want to merge these things into one executable,
> it should be a new one. "pg_util createrole bob" ?
"pg" is unfortunately already taken :(
Fwiw, let's please keep supporting "createuser". Creating login roles
is more common than non-login ones, and having to type "createrole
--login bob" is cumbersome and will cause endless support requests by
confused users.
Other idea: If we don't want to reinvent a new tool, how about
supporting prepared statements in psql?
psql -c 'create user %i' --args 'bob w. space'
Christoph