* 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
Description: Digital signature