Skip site navigation (1) Skip section navigation (2)


From: Daniel Farina <daniel(at)heroku(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Christoph Berg <cb(at)df7cb(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Runtime SHAREDIR for testing CREATE EXTENSION
Date: 2012-02-28 19:00:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Feb 26, 2012 at 7:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2012-02-25 at 14:21 +0100, Christoph Berg wrote:
>> Well, I'm trying to invoke the extension's "make check" target at
>> extension build time. I do have a temporary installation I own
>> somehwere in my $HOME, but that is still trying to find extensions in
>> /usr/share/postgresql/9.1/extension/*.control, because I am using the
>> system's postgresql version. The build process is not running as root,
>> so I cannot do an install of the extension to its final location.
>> Still it would be nice to run regression tests. All that seems to be
>> missing is the ability to put
>> extension_control_path = /home/buildd/tmp/extension
>> into the postgresql.conf of the temporary PG installation, or some
>> other way like "CREATE EXTENSION foobar WITH CONTROL
>> '/home/buildd/...'.
> Yeah, of course, the extension path is not related to the data
> directory.  So we do need some kind of path setting, just like
> dynamic_library_path.

A thought that may or may not be related:

I'd really like to support libraries (C or otherwise) of multiple
versions at the same time, when the underlying library permits.  The
critical use case is contribs that iterate on their storage format,
which right now is really painful.  While perhaps contribs should use
a version byte or something and be backwards-compatible forever, to
some extent that is clearly impossible and sometimes undesirable for
contribs that emit small on-disk representations, and would rather
use, say, the type system to disambiguate what operators fit with what

I've been struggling to think of a more graceful way to load the
correct version of extra dependencies (including non-PG intrinsic
things like libgeos or libproj) when new database replicas are
created, as well as helping people with upgrade issues.  Is this
tunable possibly related to a solution for this?


In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-02-28 19:07:08
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Previous:From: Alvaro HerreraDate: 2012-02-28 18:48:03
Subject: Re: pg_upgrade --logfile option documentation

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group