Thanks everyone for making this happen. Ciao, Gabriele
On Wed, 19 Mar 2025 at 07:42, Peter Eisentraut <pe...@eisentraut.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
