Re: Voting: "pg_ctl init" versus "initdb"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: pgsql-general(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Voting: "pg_ctl init" versus "initdb"
Date: 2009-11-14 16:22:21
Message-ID: 14032.1258215741@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Because there is doubt if someone else want this I would like to ask
> here for your opinion. There are following options:

> 1) Yeah I like pg_ctl init

> "pg_ctl init" will be preferred method and initdb will
> disappear from usr/bin in the future.

> 2) Good, but keep initdb as well

> pg_ctl init and initdb stays forever

> 3) Do not touch my lovely initdb

> pg_ctl init is nonsense, initdb is only correct way.

You have listed them in reverse preference order ;-)

The only people who would actually care about this are packagers
who think they can get away with taking initdb out of $PATH.
If you believe that you can get away with that, you can do it today
without any help from pg_ctl. (Your theory presumably is that only
one place in the initscript needs to know about it, and that one place
could just as easily invoke initdb with an explicit path to wherever.)
If you don't believe that you can get away with hiding initdb out of
sight, then this patch is useless to you.

(BTW, have you actually tried moving initdb? I wonder how well the
relative-path logic for finding SHAREDIR etc is going to cope.)

So I find the patch pretty useless. But it's also pretty harmless,
so long as it doesn't extend to the idea that we'd actually hide
initdb in a default installation; at that point you're going to start
hitting stiff resistance.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thom Brown 2009-11-14 16:37:52 Re: pgday.eu
Previous Message Greg Sabino Mullane 2009-11-14 15:28:55 Re: Upgrading databases