Re: extension_control_path and "directory" - Mailing list pgsql-hackers

From Matheus Alcantara
Subject Re: extension_control_path and "directory"
Date
Msg-id CAFY6G8dwnxqBDcQbVYfjJJ6RYMTxc04gip64Nx7X2fk4ggA+rQ@mail.gmail.com
Whole thread Raw
In response to Re: extension_control_path and "directory"  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On Fri, Apr 25, 2025 at 4:13 PM David E. Wheeler <david@justatheory.com> wrote:
>
> On Apr 25, 2025, at 09:25, Matheus Alcantara <matheusssilv97@gmail.com> wrote:
>
> > Yes, you are right. The problem was where I was asserting
> > control->control_dir != NULL. I've moved the assert after the "if
> > (!filename)" check that returns an error if the extension was not found.
> >
> > Attached v3 with this fix and also a TAP test for this scenario.
>
> That fixes the segfault, thank you.
>
Great, thanks for testing!

> > I'm just a bit confused how you get it working using /extension at the
> > end of extension_control_path since with this patch this suffix is not
> > necessary and since we hard coded append this it should return an error
> > when trying to search on something like
>
> It worked with
>
> extension_control_path = '/Users/david/Downloads/share/postgresql/extension:$system’
>
> But not with
>
> extension_control_path = '/Users/david/Downloads/share/postgresql:$system’
>
> And here is where the control file actually is:
>
> ❯ ll ~/Downloads/share/postgresql/extension  total 8
> -rw-r--r--  1 david  staff   161B Apr 24 18:07 semver.control
>
> So I don’t know the answer to your question, but it’d be handy to have functions that return a list of resolved paths
fromextension_control_path and dynamic_library_path, since they get mangled. 
>
Ok, I was testing using extension_control_path = '$system:/my/custom/path'
(starting with the macro) and it was working as expected, testing with
the macro at the end does not work.

The problem was on find_extension_control_filename() that was appending
the /extension at the end of the entire extension_control_path GUC value
instead of just the custom paths.

To append the /extension at each path on extension_control_path would
require some changes on find_in_path() that
find_extension_control_filename() calls, which I think that it would
make the function more complicated. I've them created a similar
find_in_paths() function that works in the same way but it receives a
List of paths instead of the string of paths separated by ":". We can
get this List of paths using get_extension_control_directories() that
also handle the macro substitution like find_in_path().

Attached v4 with these fixes. I hope that now you should be able to omit
the /extension from the GUC value.

--
Matheus Alcantara

Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock)
Next
From: Tom Lane
Date:
Subject: Sanding down some edge cases for PL/pgSQL reserved words