From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Matheus Alcantara <matheusssilv97(at)gmail(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-28 20:49:23 |
Message-ID: | FD339F84-2BCE-4994-B298-388EEF179892@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Apr 25, 2025, at 17:18, Matheus Alcantara <matheusssilv97(at)gmail(dot)com> wrote:
> 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.
Great example of why it’s useful to do as much testing as possible! That’s an entirely reasonable place to start testing :-)
> 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.
Oh yeah, lol, that wouldn’t work.
> 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.
Yes! It now works with this configuration:
```ini
extension_control_path = '/Users/david/Downloads/share/postgresql:$system'
dynamic_library_path = '/Users/david/Downloads/lib/postgresql:$libdir’
```
Which is nicely more consistent. Kind of want that first one to be called “share_path” now, though, since it’s not just extensions. Although I guess it’s only extension control file searching that uses it (for now).
If I understand this bit correctly:
```c
/* Substitute the path macro if needed */
mangled = substitute_path_macro(piece, "$system", system_dir);
/*
* Append "extension" suffix in case is a custom extension control
* path.
*/
if (strcmp(piece, "$system") != 0)
mangled = psprintf("%s/extension", mangled);
```
The value of `piece` is a single path from the search path, right? If so, I think it’s either `$system` or something else; I don’t it would ever be that `$system` is a substring of a single path. Is that right?
Other than that, I think this patch is good to go. Thanks!
Best,
David
`
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-04-29 03:38:57 | pgsql: Doc: Specify the interaction of publish_generated_columns with c |
Previous Message | Melanie Plageman | 2025-04-28 18:20:46 | pgsql: Add maintenance_io_concurrency flag to some read stream users |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Woodward | 2025-04-28 20:53:37 | Re: Cygwin support |
Previous Message | Nathan Bossart | 2025-04-28 18:26:34 | Re: optimize file transfer in pg_upgrade |