Re: RFC: Additional Directory for Extensions

On 14.01.25 21:01, David E. Wheeler wrote:
> I tried `prefix` with semver[3] and it did not work:
>
> ``` console
> ❯ make PG_CONFIG=~/dev/misc/postgres/pgsql-devel/bin/pg_config prefix=/Users/david/pgsql-test
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wcast-function-type -Wformat-security -Wmissing-variable-declarations -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-cast-function-type-strict -I/opt/homebrew/opt/readline/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/libxml2/include -I/opt/homebrew/opt/icu4c/include -fvisibility=hidden -I. -I./ -I/Users/david/pgsql-test/include/server -I/Users/david/pgsql-test/include/internal -I/opt/homebrew/Cellar/icu4c(at)76/76.1_1/include -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.1.sdk -I/opt/homebrew/opt/readline/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/libxml2/include -I/opt/homebrew/opt/icu4c/include -c -o src/semver.o src/semver.c
> src/semver.c:13:10: fatal error: 'postgres.h' file not found
> 13 | #include "postgres.h"
> | ^~~~~~~~~~~~
> 1 error generated.
> make: *** [src/semver.o] Error 1
> ```

prefix= should only be set when running the "install" target, not when
building (make all).

> But then it won’t load:
>
> ```psql
> postgres=# create extension semver;
> ERROR: extension "semver" has no installation script nor update path for version “0.40.0"
> ```
>
> Since `semver` uses the directory parameter[4],

Yeah, this is the problem. I'm not sure what to do about it. Setting
the directory parameter is a bit like setting an absolute rpath. You're
then stuck with that particular directory location.

> So I suspect the issue is that, when looking for SQL files, the patch needs to use the directory parameter[4] when it’s set --- and it can be an absolute path! Honestly I think there’s a case to be made for eliminating that parameter.

Possibly. I didn't know why extensions would use that parameter, before
you showed an example.

> I thought it would put the files into /Users/david/pgsql-test/extension, not /Users/david/pgsql-test/share/extension? I guess that makes sense; but then perhaps the search path should be for prefixes, in which case I’d use a config like:
>
> ``` ini
> extension_control_path = '/Users/david/pgsql-test:$system'
> dynamic_library_path = '/Users/david/pgsql-test/lib:$libdir'
> ```
>
> And the search path would append `share/extension` to each path. But then it varies from the behavior of `dynamic_library_path`. :-(

Yes exactly. This is meant to be symmetrical.

We could have a setting that just sets the top-level prefixes to search
and would thus supersede both of these settings. But then you introduce
another lay of complications, such as, the subdirectory structure under
the prefix is not necessarily fixed. It could be lib, lib/postgresql,
lib64, etc., similar under share. It's not even required that there is
a common prefix.

>>> 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.
>>
>>
>> I have solved this by just stripping off "$libdir/" from the front of the filename. This works for now. We can think about other ways to tweak this, perhaps, but I don't see any drawback to this in practice.
>
> I think this makes perfect sense. I presume it’s stripped out *before* replacing the MODULE_PATHNAME string in SQL files, yes?

No, actually it's done after. Does it make a difference?

> # Patch Review
>
> Compiles fine. All tests pass. Some comments on the docs:
>
>> <primary><varname>extension_control_path</varname> configuration parameter</primary>
>
> Although the current path explicitly searches for control files, I’d like to suggest a more generic name, since the point is to find extensions; control files are just the (current) method for identifying them. I suggest `extension_path`. Although given the above, maybe it should be all about prefixes.

If we implemented a prefix approach, then 'extension_path' could be a
good name. But right now we're not.

>> The value for <varname>extension_control_path</varname> must be a
>> list of absolute directory paths separated by colons (or semi-colons
>> on Windows). If a list element starts
>> with the special string <literal>$system</literal>, the
>
> I like this idea, though I quibble with the term `$system`, which seems like it would identify SYSCONFDIR, not SHAREDIR/extension. How about `$extdir` or, if using prefixes, `$coreprefix` or something.

I'm not attached to '$system', but I don't see how you get from that to
SYSCONFDIR. The other suggestions also have various ways of
misinterpreting them. We can keep thinking about this one.

>> Note that the path elements should typically end in
>> <literal>extension</literal> if the normal installation layouts are
>> followed. (The value for <literal>$system</literal> already includes
>> the <literal>extension</literal> suffix.)
>
> In fact, if we’re using `prefix` as currently implemented, it should end in `share/extension`, no?

It could be share/postgresql/extension, too. So I didn't want to
overdocument this, because it could vary. The examples just above this
are hopefully helpful.