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

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-16 11:14:13
Message-ID: 1258370053.1382.59.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane píše v so 14. 11. 2009 v 11:22 -0500:
> 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 ;-)

Maybe because I'm sitting on opposite hemisphere :-)

> 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.

init script is not only one place when you need initdb. init script can
do it for you but often you need to setup correct locale. And admins
need to init database manually. And after that they want to have command
for it in default path.

Another advantage of pg_ctl is that it is easy to extend it to cope with
more postgres versions and calls appropriate version of postgres or
initdb.

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

libexecdir is not used. find_other_exec() is little bit stupid. It
finds only binaries in the same directory. I guess It should look into
bindir and libexecdir as well.

when I'm thinking about it postgres and initdb should be installed into
libexecdir instead of bindir. For example sshd is in /usr/lib/sshd/ on
solaris.

> 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.

I supposed to use libexecdir for installation. If packager wants to hide
it than he can set libexecdir to another place. If not initdb will stay
in bindir.

Zdenek

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thom Brown 2009-11-16 11:48:32 Re: pgday.eu
Previous Message Jasen Betts 2009-11-16 09:37:51 Re: safelly erasing dirs/files