Re: [HACKERS] Development installation fails

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 1999-11-24, Tom Lane mentioned:
>> You may need to have env variables PGDATA and PGLIB set during initdb
>> (at least, the install docs recommended that last I looked) and you
>> definitely need to have /home/peter/postgres-cur/bin in your PATH.

> Okay, thanks for the tip. I thought about this for a while and came to the
> conclusion, that this is not only the most likely reason for the oft
> criticized installation (non-)simplicity, it is also cumbersome and not
> acceptable to have to set environment variables (especially PATH) during
> installation.

I never much cared for it either. If you can get rid of it, great!

> So I thunk that initdb could very well find out itself where it is located
> and then call ${mydir}/postgres explicitly. That solves the path problem.
> Secondly, it could also make educated guesses where the PGLIB is at
> (namely ${mydir}/../lib, or ${mydir}/../lib/pgsql as in the RPMs).

Reasonable, though you should provide a command line switch to override
the guess about PGLIB. Possibly initdb should emit a message like
"Assuming --pglib=/foo/bar/baz" if it's not given a switch.

> So please examine that patch. It was a very quick hack, so it's not very
> refined. Let me know if this sounds good, then I'll put the finishing
> touches on it.

I'm not convinced your "which $0" implementation for finding BINDIR is
portable/reliable. On my system, man which says that it determines
aliases and path by reading ~/.cshrc, which has got obvious problems if
I'm not a csh user. My references say that "which" isn't available on
all systems anyway. It'd probably be a good idea to verify that
$BINDIR/postgres exists after you think you have the value.

BTW, seems like doing PATH=$BINDIR:$PATH in the script would be a lot
easier than hacking all the references to programs --- and it covers
the possibility that one of the invoked programs tries to call another.

The other bit of environment state that initdb currently depends on is
USER. This is a big risk factor IMHO, since it won't be right if you
are su'd to the postgres account. Can you add code to verify that it
is set (or set it if not) and that it matches the actual ownership of
the process?

regards, tom lane