Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1

On Mon, Jun 02, 2025 at 07:56:01PM -0300, Matheus Alcantara wrote:
> On 02/06/25 16:56, Rahila Syed wrote:
>> Currently, the tests seem to be failing as follows for windows:
>>
>> [19:07:13.107] #   Failed test 'create extension from custom extension
>> control path'[19:07:13.107] #   at
>> C:/cirrus/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
>> line 102.[19:07:13.107] #          got: '2'[19:07:13.107] #
>> expected: '0'[19:07:13.107] # Looks like you failed 1 test of
>> 7.[19:07:13.107] [19:07:13.107] (test program exited with status code
>> 1)
>>
>> Details here:  Windows - Server 2019, VS 2019 - Meson & ninja - Cirrus CI
>> <https://cirrus-ci.com/task/5241991606304768>
>
> Fixed, v2 attached. The 0001 patch remains the same as v1.

I am adding an open item for Peter Eisentraut, for 4f7f7b037585.  The
patch looks sensible at quick glance, I did not check it in details
regarding the internals of dfmgr.c.

I don't like much the tests you are adding here.  First, the
cross-platform requirements to copy a library to the plugins/ folder
is annoying.  The actual issue is that we don't have an installation
rule to be able to install a library to a plugins/ path to allow
non-superusers to load it, no?  I mean, as 4f7f7b037585 states, we
have a `make install prefix=/else/where` but the TAP tests cannot
shape a temporary installation with it.  If we had something like that
for meson and makefiles, we could then reuse EXTRA_INSTALL to force a
library to exist where we want it to be, for the sake of testing
coverage.

I am not completely sure that the tests are completely waterproof,
either.  Some distributions like fancy installation folder layers,
like Debian, and such things have proven to break these folk's tests.
Having a centralized rule could be also useful for out-of-core
extensions, to give these a way to install something inside a plugins/
folder.  At least that may be better than requiring pg_config to get
the basic library install path.

Second, requiring dummy_index_am inside the tests test_extensions is
adding unwelcome complexity across the test modules.
--
Michael