Re: Potential problem in commit f777d773878 and 4f7f7b03758
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Peter Eisentraut <peter@eisentraut.org>,
Matheus Alcantara <matheusssilv97@gmail.com>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-04T12:02:27Z
Lists: pgsql-hackers
On Thu, Sep 4, 2025 at 5:13 PM Álvaro Herrera <alvherre@kurilemu.de> wrote: > > On 2025-Aug-27, Peter Eisentraut wrote: > > > > > > On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla > > > > > <srinath2133@gmail.com> wrote: > > > > > > > > > > > > Thanks Dilip and Matheus for working on this , i reviewed the > > > > > > latest patch given [by] 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 > > > committed, thanks > > Was the above-quoted complaint addressed in some way? I see that Dilip > and Matheus disregarded as not important, but I'm not so sure that > that's really true. What's the complain, Srinath complained that if you try to LOAD '$libdir/foo' explicitly then it should load this from $libdir path and it will indeed do so because it will directly call expand_dynamic_library_name() and in this function if there is '/' it will replace the $libdir macro with pkglib_path which is right thing to do so it would behave as expected, am I missing something? -- Regards, Dilip Kumar Google
Commits
-
Fix: Don't strip $libdir from nested module_pathnames
- d07e2d4237cb 18.0 landed
- 990c8db1827c 19 (unreleased) landed
-
Don't strip $libdir from LOAD command
- f777d773878d 18.0 cited