Re: Potential problem in commit f777d773878 and 4f7f7b03758 - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Potential problem in commit f777d773878 and 4f7f7b03758
Date
Msg-id CAFiTN-vkA01=BnLGTWBCii89g_ui0rFKzebd475U8aH+z-=+Ng@mail.gmail.com
Whole thread Raw
In response to Re: Potential problem in commit f777d773878 and 4f7f7b03758  (Álvaro Herrera <alvherre@kurilemu.de>)
List 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



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: NOT NULL NOT ENFORCED
Next
From: Dean Rasheed
Date:
Subject: Re: Inconsistent update in the MERGE command