Re: pgxs problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgxs problem
Date
Msg-id 16367.1153346965@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgxs problem  (Michael Fuhr <mike@fuhr.org>)
List pgsql-hackers
Michael Fuhr <mike@fuhr.org> 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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pgxs problem
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Max size of a btree index entry