Re: extension_control_path

On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
> What about allowing a control file like this:
>
> # hstore extension
> comment = 'data type for storing sets of (key, value) pairs'
> default_version = '1.3'
> directory = 'local/hstore-new'
> module_pathname = '$directory/hstore'
> relocatable = true

I think your previously proposed patch to add extension_control_path
plus my suggestion to update existing de facto best practices to not
include $libdir into the module path name (thus allowing the use of
dynamic_library_path) will address all desired use cases just fine.

Moreover, going that way would reuse existing facilities and concepts,
remove indirections and reduce overall complexity. This new proposal,
on the other hand, would go the other way, introducing new concepts,
adding more indirections, and increasing overall complexity, while
actually achieving less.

I see an analogy here. What we are currently doing is similar to
hardcoding absolute rpaths into all libraries. Your proposal is
effectively to (1) add the $ORIGIN mechanism and (2) make people use
chrpath when they want to install somewhere else. My proposal is to get
rid of all rpaths and just set a search path. Yes, on technical level,
this is less powerful, but it's simpler and gets the job done and is
harder to misuse.

A problem with features like these is that they get rarely used but
offer infinite flexibility, so they are not used consistently and you
can't rely on anything. This is already the case for the
module_pathname setting in the control file. It has, AFAICT, no actual
use, and because of that no one uses it, and because of that, there is
no guarantee that extensions use it sensibly, and because of that no one
can ever make sensible use of it in the future, because there is no
guarantee that extensions have it set sensibly. In fact, I would
propose deprecating module_pathname.