Re: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?
Date
Msg-id 20230603125016.ssjjowmdjn3ydfir@jrouhaud
Whole thread Raw
In response to Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?
List pgsql-hackers
On Sat, Jun 03, 2023 at 02:56:27PM +0300, Aleksander Alekseev wrote:
>
> I tried to use `REGRESS_OPTS = --temp-config` in order to test a 3rd
> party extension with a custom .conf file similarly to how PostgreSQL
> does it for src/test/modules/test_slru. It didn't work and "38.18.
> Extension Building Infrastructure" [1] doesn't seem to be much help.
>
> Is it accurate to say that the author of a 3rd party extension that
> uses shared_preload_libraries can't be using SQL tests and has to use
> TAP tests instead? If not then what did I miss?

temp-config can only be used when bootstrapping a temporary environment, so
when using e.g. make check.  PGXS / third-party extension can only use
installcheck, so if you need specific config like shared_preload_libraries you
need to manually configure your instance beforehand, or indeed rely on TAP
tests.  Most projects properly setup their instance in the CI jobs, and at
least the Debian packaging infrastructure has a way to configure it too.



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid unused value (src/fe_utils/print.c)
Next
From: Aleksander Alekseev
Date:
Subject: Re: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?