On Sun, Feb 26, 2012 at 7:36 AM, Peter Eisentraut <peter_e@gmx.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
data.
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?
--
fdr
