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@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.
