Re: Potential problem in commit f777d773878 and 4f7f7b03758

On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla
<srinath2133@gmail.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


-- 
Regards,
Dilip Kumar
Google