Thread: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?

Hi,

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.

Here is my Makefile:

```
EXTENSION = experiment
MODULES = experiment
DATA = experiment--1.0.sql experiment.conf
REGRESS_OPTS = --temp-config
$(top_srcdir)/../../../share/postgresql/extension/experiment.conf
REGRESS = experiment

PG_CPPFLAGS = -g -O0
SHLIB_LINK =

ifndef PG_CONFIG
    PG_CONFIG := pg_config
endif
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
```

And the result I get:

```
$ make clean && make install && make installcheck
...

# note: experiment.conf is copied according to DATA value:

/bin/sh /Users/eax/pginstall/lib/postgresql/pgxs/src/makefiles/../../config/install-sh
-c -m 644 .//experiment--1.0.sql .//experiment.conf
'/Users/eax/pginstall/share/postgresql/extension/'

# note: --temp-conf path is correct

echo "# +++ regress install-check in  +++" &&
/Users/eax/pginstall/lib/postgresql/pgxs/src/makefiles/../../src/test/regress/pg_regress
--inputdir=./ --bindir='/Users/eax/pginstall/bin'    --temp-config
/Users/eax/pginstall/lib/postgresql/pgxs/src/makefiles/../../../../../share/postgresql/extension/experiment.conf
--dbname=contrib_regression experiment
# +++ regress install-check in  +++
# using postmaster on Unix socket, default port
not ok 1     - experiment                                382 ms

# note: shared_preload_libraries had no effect and I got elog() from
the extension:

$ cat /Users/eax/projects/c/postgresql-extensions/007-gucs/regression.diffs
...
+FATAL:  Please use shared_preload_libraries
```

This comment in Makefile for test_slru seems to explain why this happens:

```
# Disabled because these tests require "shared_preload_libraries=test_slru",
# which typical installcheck users do not have (e.g. buildfarm clients).
NO_INSTALLCHECK = 1
```

The complete example is available on GitHub [2].

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?

[1]: https://www.postgresql.org/docs/current/extend-pgxs.html
[2]: https://github.com/afiskon/postgresql-extensions/tree/temp_config_experiment/007-gucs

-- 
Best regards,
Aleksander Alekseev

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.

Hi Julien,

> 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.

Many thanks!

-- 
Best regards,
Aleksander Alekseev