Re: RFC: Additional Directory for Extensions

Thanks everyone for making this happen.

Ciao,
Gabriele

On Wed, 19 Mar 2025 at 07:42, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:

> On 12.03.25 14:17, Matheus Alcantara wrote:
> >> There should be a simpler way into this. Maybe
> >> pg_available_extensions() should fill out the ExtensionControlFile
> >> structure itself, set ->control_dir with where it found it, then call
> >> directly to parse_extension_control_file(), and that should skip the
> >> finding if the directory is already set. Or something similar.
> >>
> > Good catch. I fixed this by creating a new function to construct the
> > ExtensionControlFile and changed the pg_available_extensions to set the
> > control_dir. The read_extension_control_file was also changed to just
> > call this new function constructor. I implemented the logic to check if
> > the control_dir is already set on parse_extension_control_file because
> > it seems to me that make more sense to not call
> > find_extension_control_filename instead of putting this logic there
> > since we already set the control_dir when we find the control file, and
> > having the logic to set the control_dir or skip the find_in_path seems
> > more confusing on this function instead of on
> > parse_extension_control_file. Please let me know what you think.
>
> Committed that, thanks.
>
> A small tweak I made was to replace palloc+snprintf by psprintf. Maybe
> you were not aware that that function exists.
>
> I also simplified the error handling in parse_extension_control_file() a
> bit. If we pass in a control directory (which is the new code we're
> adding), then we can assume that we already found the file earlier, and
> then if we now don't find it, then we should just report the file system
> error instead of the "you should install this extension first" error.
> It's kind of a "can't happen" error anyway, so the different is small.
>
>

--
Gabriele Bartolini
VP, Chief Architect, Kubernetes
enterprisedb.com