Re: extension_control_path - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: extension_control_path
Date
Msg-id 531A8E42.2080703@gmx.net
Whole thread Raw
In response to Re: extension_control_path  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
[I answered most of these concerns in more detail in the reply to Dimitri.]

On 3/7/14, 9:16 AM, Stephen Frost wrote:
> Being able to have a self-contained module which requires a minimum of
> modification to postgresql.conf is a reduction in complexity, imv.
> Having to maintain two config options which will end up being overly
> long and mostly duplicated doesn't make things easier for people.

Then we can make it one path.

> This
> has made me wonder if we could allow a control file to be explicitly
> referred to from CREATE EXTENSION itself, dropping the need for any of
> this postgresql.conf/GUC maintenance.  There are downsides to that
> approach as well, of course, but it's definitely got a certain appeal.

That might be useful as a separate feature, but it reeks of #include
</absolute/path/file.h>, which isn't a sane practice.  No programming
language other than ancient or poorly designed ones allows that sort of
thing.

> I don't buy off on this analogy.  For starters, you can change the
> control file without needing to rebuild the library,

(You can also change the rpath without rebuilding the library.)

> but the main
> difference is that, in practice, there are no library transistions
> happening and instead what we're likely to have are independent and
> *incompatible* libraries living with the same name in our path.

I understand this concern.  The question is, how big is it relative to
the other ones.

As side idea I just had, how about embedding the extension version
number into the library somehow?  Food for thought.

> This makes sense when you have complete control over where things are
> installed to and can drop the control file into the "one true directory
> of control files" and similairly with the .so.  Indeed, that works
> already today for certain platforms, but from what I understand, on the
> OSX platform you don't really get to just dump files anywhere on the
> filesystem that you want and instead end up forced into a specific
> directory tree.

That is incorrect.

If someone has a general use for module_pathname, I'd be interested to
hear it, but that's not one of them.




pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Amit Kapila
Date:
Subject: Re: pg_ctl status with nonexistent data directory