Re: Potential problem in commit f777d773878 and 4f7f7b03758

On Tue, Aug 26, 2025 at 11:31 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla
> <srinath2133(at)gmail(dot)com> wrote:
> >
> > Hi,
> > Thanks Dilip and Matheus for working on this , i reviewed the latest patch given my Matheus and it LGTM but i have doubt that in f777d773878 commit the $libdir was moved out from expand_dynamic_library_name into load_external_function because if someone specifies LOAD '$libdir/foo' explicitly they want to get the foo.so from $libdir not from other paths given in dynamic_library_path ,i think same should go for the case when we do "create extension" will try to execute the sql script which will replace the MODULE_PATHNAME with module_pathname from .control file lets say which is $libdir/foo ,now during the sql functions execution this calls the load_external_function where we strip $libdir and we are going to load the foo.so from other paths specified in dynamic_library_path, isn't that a problem , i think this case is also same as with the LOAD.
>
> IMHO the cases like $libdir/foo is not a problem because first we will
> strip the $libdir and then we will try to find the foo in the
> 'dynamic_library_path' and the default value of dynamic_library_path
> is $libdir so everything should work fine. OTOH the case I report has
> $libdir/xyz/foo, in this case it doesn't search in
> 'dynamic_library_path' instead try to replace the $libdir macro, but
> we have already stripped the $libdir so this will not behave
> correctly, so if we have any extra slash in path we need to retain the
> $libdir

Please find the revised patch with improved comments and commit messages.

@Peter Eisentraut since you committed this feature, so tagging you to
see do you think this needs to be fixed? Thanks.

--
Regards,
Dilip Kumar
Google