Re: RFC: Additional Directory for Extensions

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.