Re: extension_control_path

[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.