Zdenek Kotala wrote:
1) Yeah I like pg_ctl init
"pg_ctl init" will be preferred method and initdb will
disappear from usr/bin in the future.
I agree with this position. My own database wrapper scripts work this
way already, and it would be nice for them to have one more command that
maps directly to a pg_ctl call rather than needing to special-case
initdb instead. There's also the precedent that the RPM scripts provide
an "initdb" target so that the user doesn't need to know how to use
initdb directly; in the field, that's what I tell people to use when in
an RPM environment, rather than calling initdb directly.
I believe that the fact that there's this separate binary named "initdb"
you only call once, and that has a name unlike all of the rest of the
binaries, would be considered a bad design were that decision being made
from a UI and packaging perspective right now. Zdenek is completely
correct to identify this inconsistency, the tiny bump it adds to the
learning curve, and the difficulty it adds to packaging as things that
should be improved. Every unique thing you have to know in order to
start using the database costs a little bit of time, and I'm always in
favor of anything that removes one of those from the list, even if it's
a small one. If anything, I think you're not going far enough. Not
only should "pg_ctl init" work, "pg_ctl start" should be more helpful in
the way "service postgresql start" is--suggesting to the user that they
need the init step if the cluster doesn't exist.
That said, I wouldn't even bother trying to get such a change committed,
as this project actively resists changes that impact backward
compatibility merely to improve the inexperienced user experience. It
will be an uphill battle the whole way, beset by people who don't have
to spend enough time with PostgreSQL newbies enough to appreciate what
they struggle with. If I could avoid having to teaching them initdb,
and instead just mention it as another option during the pg_ctl lesson,
that would be one less thing to have to train on.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@xxxxxxxxxxxxxxx www.2ndQuadrant.com
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
