Re: Potential problem in commit f777d773878 and 4f7f7b03758

From: Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Potential problem in commit f777d773878 and 4f7f7b03758
Date: 2025-08-24 23:46:15
Message-ID: CAFC+b6rU-Qy5u-eZRiObOdp-AzL0gKWr-R6LwSyyircBf3a-5Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 24, 2025 at 5:58 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.
>

sorry i missed to mention "stripping of $libdir" here " but i have a doubt
that in f777d773878 commit the stripping of $libdir was moved out
from expand_dynamic_library_name into load_external_function "

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-08-25 00:00:00 minor refactor on src/test/modules/test_ddl_deparse/sql/alter_table.sql
Previous Message Nico Williams 2025-08-24 23:42:29 Re: Non-reproducible AIO failure