* Peter Eisentraut (pete...@gmx.net) wrote: > 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.
You still haven't addressed how to deal with the case of multiple .so's
with the same name ending up in the dynamic_library_path. I don't see
that as unlikely to end up happening either.
> 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.
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. 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.
> 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.
I don't buy off on this analogy. For starters, you can change the
control file without needing to rebuild 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.
> 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.
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.
Thanks,
Stephen
signature.asc
Description: Digital signature
