Question

I’m writing a script that will install some of the optional postgresql modules. Is there a way to programmatically figure out where the contrib directory is or do I have to prompt for the path? I’ve looked at a few examples and it seems inconsistent; doesn’t appear in pg_config.

(The script might be run on OS X or linux, and I can’t make assumptions about how postgresql was installed).

Answer 1

There is no easy works everywhere answer to this, so it’s a matter of how much intelligence you want to try and put into your installer. And for some people it will be impossible to do what you hope for, the best you’ll be able to do is offer guidance about what’s missing. There is a lot of variation on packaging here between Linux distributions, versions of PostgreSQL, and the various ways you can install PostgreSQL on OS X (MacPorts, homebrew, etc.)

First off, only source code installs will have a contrib directory with source code in it that allows building the optional modules. In the packaged builds for Linux, all the contrib binaries may only be available via an optional package, called something like postgresql-contrib. That’s the only way to make the optional modules that come with the database available: install the package the binaries are included in. You may see some variation in the OS X builds here too.

If you want to install extensions (what these are officially called as of PostgreSQL 9.1 now, rather than ‘modules’) using binaries you provide instead, what you then want to know is where to put the resulting shared libraries and matching SQL files that reference them. What pgconfig returns for pkglibdir will tell you where the binaries go, while sharedir points toward the default place to put the SQL. Providing binaries is a losing game though; the job of syncing with every platform to build them is a huge one.

And here are the sort of additional complications you’ll run into in this area, if you wanted to ship source code and try to build things yourself in an automatic way:

• PostgreSQL 9.1 now installs these using the CREATE EXTENSION
  mechanism, so you’ll need to handle both the pre-9.1 method and the
  new one introduced there.

• Not all PostgreSQL installations will have
  pg_config. It’s considered a development tool, and which package it
  gets bundled with (and whether that package is mandatory or not)
  varies. Debian/Ubuntu put it into the optional liqpq-dev, RedHat
  derived RPMs have it in postgresql-devel or
  postgresql-[version]-devel.

• Due to pg_config being necessary for
  compiling the new 9.1 extensions, packagers have started
  reconsidering where pg_config goes; it’s considered a lot more
  important now than it used to be. 9.1 or later packages might alter which package it’s contained in. That doesn’t really change what you can and can’t do though. It just impacts what advice you might offer for correcting situations your program can’t deal with.

• I’ve been describing the standard
  Linux packaging here when I talk about that OS. There are also installers for both Linux and
  OS X from EnterpriseDB, what they call their “one-click installers”.
  These use a different standard altogether for what people do and don’t get installed in this area. I don’t follow the commercial packaging to know what is actually different, but it’s another variable you can expect people to encounter.

• Recent OS X versions may
  have some system PostgreSQL components floating around too. No idea
  yet how this handle extensions though.

Basically, all three of version/packager/platform can vary how this will work, and the idea that you’ll find any solution that handles even the majority of those permutations is optimistic. Installing extensions is known to be difficult in PostgreSQL, which is one thing that motivated all the 9.1 changes to turn it into a simple CREATE EXTENSION for many of them. But for now, those changes have just added another whole set of variation into the mix, actually making this harder during the transition period. It will be a while until PostgreSQL versions supporting that are the only ones in popular use.