Thread: pgxs problem
I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src. These lines seem to be the culprits: bindir := $(shell pg_config --bindir) datadir := $(shell pg_config --sharedir) sysconfdir := $(shell pg_config --sysconfdir) libdir := $(shell pg_config --libdir) pkglibdir := $(shell pg_config --pkglibdir) includedir := $(shell pg_config --includedir) pkgincludedir := $(shell pg_config --pkgincludedir) mandir := $(shell pg_config --mandir) docdir := $(shell pg_config --docdir) localedir := $(shell pg_config --localedir) I think it should be running $(pkglibdir)/bin/pg_config -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Wed, Jul 19, 2006 at 05:06:48AM -0400, Gregory Stark wrote: > > I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src. > These lines seem to be the culprits: <snip> > I think it should be running $(pkglibdir)/bin/pg_config Seems reasonable to me. This code definitly seems to be limiting you to one installation per machine. Setting the PATH would probably work too. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Gregory Stark <gsstark@mit.edu> writes:
> I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src.
> These lines seem to be the culprits:
> bindir := $(shell pg_config --bindir)
> datadir := $(shell pg_config --sharedir)
> sysconfdir := $(shell pg_config --sysconfdir)
> libdir := $(shell pg_config --libdir)
> pkglibdir := $(shell pg_config --pkglibdir)
> includedir := $(shell pg_config --includedir)
> pkgincludedir := $(shell pg_config --pkgincludedir)
> mandir := $(shell pg_config --mandir)
> docdir := $(shell pg_config --docdir)
> localedir := $(shell pg_config --localedir)
> I think it should be running $(pkglibdir)/bin/pg_config
Your reasoning is circular. How are we to find out pkglibdir, if not
by asking pg_config? (It's the wrong path anyway, since pkglibdir
isn't where pg_config lives...)
The documented behavior is that pgxs invokes whatever pg_config is in
your PATH.
regards, tom lane
Gregory Stark wrote: > I've tracked down my problem with pgxs to Makefile.global in > lib/pgxs/src. These lines seem to be the culprits: > > bindir := $(shell pg_config --bindir) Yes, that's pretty small-minded. It should be something like PG_CONFIG = pg_config bindir := $(shell $(PG_CONFIG) --bindir) That way you can override it. > I think it should be running $(pkglibdir)/bin/pg_config Actually pg_config is defined to live in $(bindir), so that would be wrong. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Wed, Jul 19, 2006 at 10:29:14AM -0400, Tom Lane wrote: > The documented behavior is that pgxs invokes whatever pg_config is in > your PATH. 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). For example, I'd type "pg73 psql" to run the 7.3 version of psql (which would connect to a 7.3 server) and I'd type "pg82 gmake" to build an extension for 8.2devel. Prefixing each command with pgXX is a minor nuisance but by being explicit I always know what version I'm using. What are others doing? -- Michael Fuhr
Michael Fuhr wrote: > On Wed, Jul 19, 2006 at 10:29:14AM -0400, Tom Lane wrote: > >>The documented behavior is that pgxs invokes whatever pg_config is in >>your PATH. > > 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). For example, I'd > type "pg73 psql" to run the 7.3 version of psql (which would connect > to a 7.3 server) and I'd type "pg82 gmake" to build an extension > for 8.2devel. Prefixing each command with pgXX is a minor nuisance > but by being explicit I always know what version I'm using. > > What are others doing? > I use something very similar that Tom Lane sent me a while back. The only difference is I type, say, "pg81" just once, and it sets up my environment for 8.1 (PATH, LD_LIBRARY_PATH, PGDATA, etc). From that point on I just use normal commands. Works great for me. Joe
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
Peter Eisentraut <peter_e@gmx.net> writes:
> Yes, that's pretty small-minded. It should be something like
> PG_CONFIG = pg_config
> bindir := $(shell $(PG_CONFIG) --bindir)
> That way you can override it.
No objection here, although I'm not entirely convinced why anyone would
prefer doing that to setting their PATH. If the pg_config you want
isn't (first in) your PATH, none of the other PG programs will be
either, which seems like an awkward situation for getting any PG-related
work done.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Yes, that's pretty small-minded. It should be something like > > PG_CONFIG = pg_config > > bindir := $(shell $(PG_CONFIG) --bindir) > > That way you can override it. > > No objection here, although I'm not entirely convinced why anyone > would prefer doing that to setting their PATH. If the pg_config you > want isn't (first in) your PATH, none of the other PG programs will > be either, which seems like an awkward situation for getting any > PG-related work done. Well, with the above change, both camps would be happy. -- Peter Eisentraut http://developer.postgresql.org/~petere/