Re: extension_control_path and "directory"
От | Matheus Alcantara |
---|---|
Тема | Re: extension_control_path and "directory" |
Дата | |
Msg-id | CAFY6G8dwnxqBDcQbVYfjJJ6RYMTxc04gip64Nx7X2fk4ggA+rQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: extension_control_path and "directory" ("David E. Wheeler" <david@justatheory.com>) |
Ответы |
Re: extension_control_path and "directory"
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: