Portability (was Re: [HACKERS] Development installation fails)

On 1999-11-29, Tom Lane mentioned:

> > To make a long story short, using the implementation I suggested with the
> > checks you suggested would probably benefit 90% of our users.
>
> And fail entirely for the other 10%? Not good enough if so :-( ... the
> idea is to make install easier not harder. How much code would it take
> to emulate as much of "which" as we need, do you think? What's our
> fallback position if it doesn't work?

Okay, now you're putting words into my mouth :) The fallback would be not
needing "which" because initdb is called with an explicit path (which is
fairly likely during installation, unless you adjust your path ahead of
time) and also behaviour as it is now (always a good idea).

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. (And I
don't know awk, but that's just an excuse, no reason.)

> After thinking about it for a while, I think that there shouldn't be any
> dependency on USER, period. initdb (and anything else that cares) ought
> to get the name of the user they are executing as, and use that. I
> can't see any good reason why the name inserted into the databases
> should be potentially different from the ownership of the files.

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

> Is 'whoami' a portable way of getting the current user id, or not?
> The only reference I have about portable shell programming says that
> the POSIX-approved command for this is 'id -u -n', and that 'whoami'
> is a BSD-ism. I've got doubts that either one is universal ... we might
> have to try both. Grumble.

(The psql wrapper scripts use "whoami".)

Once you start wondering in this direction you might soon start noticing
that chances are that shell scripts cannot reliably use *any* external
program. The exceptions might be the handful listed in the GNU makefile
standard, because as we are using autoconf we could assume that they are
present.

We have already taken one step into the direction of providing our own sh
utils collection by way of pg_id (which is also a subset of what "id"
does). We could extend that and provide pg_which and whatever else we need
(of course pg_which will create a chicken and egg problem). But that could
get out of hand and won't help developers either.

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. In practice it is probably safer to say
POSIX to the extend to which it is supported by the most popular operating
systems.

That doesn't mean others should be locked out, but then *they* should have
to make the adjustments. That means if all reasonable systems have "id"
then the others will have to get a substitute. This also applies to C
source code: If all reasonable systems have CONSTANT defined, then others
will have to define it themselves (possibly assisted via autoconf), but
you should not expect your developers to remember every single constant
you invented yourself because of some obscure conflict. (Yes, I'm also
alluding to PATH_MAX, but it goes further to C functions etc. Recall the
postmaster SSL switch.) But most importantly of all you should not reject
useful extensions because of strange incompatibilities.

We can easily steal the relevant working utilities from some *BSD* code
and provide them as an extra tar ball. "To use PostgreSQL, you need
certain basic 'shell utilility' programs, which you do not seem to have
installed. Please grab the package pgsql-shutils.tar.gz from the
PostgreSQL ftp server. You'll be eternally grateful." Or even include them
in the main tarball, if they aren't too large.

I think the best we could possibly do at this point is to do a survey of
operating systems we support and which are mostly used and see what's
really on there and what POSIX says and then use that as a frame of
reference. Those OS' should probably include *BSD, BSDI, Linux (various
distros), Solaris, SGI, HPUX, Cygwin, (shoot me if I left yours off). I
think the developer circle does have access to all of those. If not, then
it's potentially pointless to *try* to account for them, if we really
can't anyway. This whole portability discussion needs to have a reference.
We can't just always say "I think it's not portable." We need to have a
way to look it up.

Having said that, I'll continue to mess around with initdb on the
assumption that nothing works and we'll see what comes out of it. Thanks
for reading all the way down to here anyway.

-Peter

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden