Re: Portability (was Re: [HACKERS] Development installation fails) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Portability (was Re: [HACKERS] Development installation fails)
Date
Msg-id 21083.943978729@sss.pgh.pa.us
Whole thread Raw
In response to Portability (was Re: [HACKERS] Development installation fails)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Portability (was Re: [HACKERS] Development installation fails)
Re: Portability (was Re: [HACKERS] Development installation fails)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> To reproduce "which" one would need to do some sort of split on PATH,
> which would probably require awk and we're trying to avoid that.

No, that part is easy:

for dir in `echo $PATH | sed 's/:/ /g'` ; do if [ -x $dir/initdb ]; then   ...

I think the harder part is manipulating $0 to see if it contains a path
part or not --- not all systems have dirname, so you need to fake it
with a sed pattern.  See the configure script for the standard way.
(BTW, I see the new run_check.sh driver depends on dirname ... boo hiss.)

> One potential goal (which I personally share) of simplifying the
> installation process would be to not have to su as postgres but do
> everything as root or a user of your choice. Together with Vince's idea of
> adding -o and -g options to the install command and a similar option to
> initdb, we can do that and it would not be hard to understand from an end
> user's point of view.

Huh?  The user of your choice *is* postgres, or whoever you are su'd as.
-o and -g are useless unless you are executing the install as root,
which really isn't necessary --- in fact I think we ought to discourage
it to prevent people from accidentally installing the postgres files
with root ownership.  (initdb ought to refuse to run at all as root...)

> What I don't like is that certain scripts don't find
> the USER variable set and then set it themselves. The psql wrapper scripts
> do that, but I'm cleaning that up.

Well, if you don't like setting USER I don't have a problem with using
a different variable name instead.  My point is that there is no good
reason to allow the value to be different from the actual effective UID,
so we should be working from that and not environment variables at all.

> One thing I am missing from this project that could really help is a goal
> of what sort of operating system it is we are trying to support. In the
> beginning the answer was clearly "BSD". Nowadays I believe everyone would
> agree that it should be POSIX.

POSIX, BSD, and anything else that anyone in the developer + beta tester
population is willing to test/support.  In practice, as long as we are
pretty conservative about what we assume is in POSIX or BSD (eg, use
POSIX.1 but not POSIX.2 stuff), I don't think it's a big deal.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [ADMIN] When postgres will be faster?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] sort on huge table