On Tue, Aug 26, 2025 at 11:31 AM Dilip Kumar <[email protected]> wrote: > > On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla > <[email protected]> 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
v1-0001-Fix-Don-t-strip-libdir-from-nested-module_pathnam.patch
Description: Binary data
