Michael Fuhr <[EMAIL PROTECTED]> writes:
> How do people with multiple PostgreSQL installations keep track of
> which installation they're using? I use shell scripts that set
> PATH and a few other environment variables and then exec the command
> I want to run (shell aliases would also work).
Yeah, I do something similar. In my case I generally want to switch my
attention to different installations at different times, so what I do
is make shellscripts that adjust PATH and other variables. Then I type
eg ". setv81" to switch into the environment for my REL8_1_STABLE tree.
(Need the "." because just executing the script normally would fail to
affect the parent shell's variables.) The script itself looks like
# Source this, eg with ". bin/setvariables", to prepare for Postgres work.
STDPATH=${STDPATH:-$PATH}
STDMANPATH=${STDMANPATH:-$MANPATH}
PGSRCROOT=$HOME/REL8_1/pgsql
PGBLDROOT=$PGSRCROOT
PGINSTROOT=$HOME/version81
PATH=$PGINSTROOT/bin:$STDPATH
DEFPORT=5481
MANPATH=$PGINSTROOT/man:$STDMANPATH
PGDATA=$PGINSTROOT/data
PMOPTIONS="-p 5481 -i -F"
PMLOGFILE=server81.log
export PGSRCROOT PGBLDROOT PGINSTROOT PATH MANPATH STDPATH STDMANPATH
export DEFPORT PGDATA PMOPTIONS PMLOGFILE
The reason for the passel of variables is that I have some other scripts
that use the variables to "do the right thing" in all installations.
For instance the script that invokes configure includes
--with-pgport="$DEFPORT" --prefix="$PGINSTROOT"
In particular the point of STDPATH/STDMANPATH is to capture the shell's
original path settings so that switching between installations
repeatedly doesn't cause PATH and MANPATH to grow indefinitely.
You can probably guess what all the other vars are for.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
