Re: RFC: Additional Directory for Extensions
David E. Wheeler <david@justatheory.com>
From: "David E. Wheeler" <david@justatheory.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Craig Ringer <craig.ringer@enterprisedb.com>,
Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-11-18T19:19:07Z
Lists: pgsql-hackers
Hi Peter, Making another pass at this proposal, I’m a bit confused by this issue: On Nov 12, 2024, at 09:44, David E. Wheeler <david@justatheory.com> wrote: >>>> - The biggest problem is that many extensions set in their control file >>>> >>>> module_pathname = '$libdir/foo' >>>> >>>> This disables the use of dynamic_library_path, so this whole idea of installing an extension elsewhere won't work that way. The obvious solution is that extensions change this to just 'foo'. But this will require a lot updating work for many extensions, or a lot of patching by packagers. > > Yeah, '$libdir/foo' has been the documented way to do it for quite some time, as I recall. Perhaps the behavior of the MODULE_PATHNAME replacement function could be changed to omit $libdir when writing the SQL files? Elsewhere you write: > Nothing changes about shared library files. They are looked up in dynamic_library_path or any hardcoded file name. And also point out that the way to install them is: ``` make install datadir=/else/where/share pkglibdir=/else/where/lib ``` So as long as dynamic_library_path includes /else/where/lib it should work, just as before, no? Best, David
Commits
-
doc: Flesh out extension docs for the "prefix" make variable
- 0064020680c1 18.0 landed
-
Fix extension control path tests
- b7076c1e7f43 18.0 landed
-
extension_control_path
- 4f7f7b037585 18.0 landed