From: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: extension_control_path and "directory" |
Date: | 2025-04-25 21:18:58 |
Message-ID: | CAFY6G8dwnxqBDcQbVYfjJJ6RYMTxc04gip64Nx7X2fk4ggA+rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, Apr 25, 2025 at 4:13 PM David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
> On Apr 25, 2025, at 09:25, Matheus Alcantara <matheusssilv97(at)gmail(dot)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 from extension_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 | Content-Type | Size |
---|---|---|
v4-0001-Make-directory-work-with-extension-control-path.patch | application/octet-stream | 11.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2025-04-26 15:41:49 | pgsql: doc: improve wording of vacuum_max_eager_freeze_failure_rate |
Previous Message | David E. Wheeler | 2025-04-25 19:13:02 | Re: extension_control_path and "directory" |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-25 21:44:05 | Sanding down some edge cases for PL/pgSQL reserved words |
Previous Message | Matthias van de Meent | 2025-04-25 21:13:14 | [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock) |