Problem
Some pgxntool variables are set with plain = after include $(PGXS) in base.mk, which means there is no way for a user to override them regardless of where they set values in their own Makefile. The most impactful case:
# base.mk — after include $(PGXS)
CONTRIB_TESTDB = $(REGRESS_DBNAME)
where REGRESS_DBNAME is computed as:
REGRESS_DBNAME = $(or $(PGXN),regression)_$(REGRESS_DBHASH)
and REGRESS_DBHASH is a hash of $(CURDIR). The result is a database name like cat_tools_dd113 — automatically derived, with no supported way to specify a different name.
Why this matters
- Users running tests in environments with a specific pre-existing database (e.g. CI setups, shared servers) cannot tell pgxntool which database to use.
- The
?= pattern works for variables set before PGXS is included, but once PGXS runs and pgxntool reassigns with =, any prior user setting is silently clobbered.
PGXNTOOL_NO_PGXS_INCLUDE=1 is the only current escape hatch, but it disables all of PGXS — a sledgehammer for what should be a simple knob.
Scope
This is a specific instance of a more general pattern: any variable that pgxntool sets with = or := after include $(PGXS) is effectively non-overridable. A systematic review of post-PGXS assignments should identify all such cases and decide for each whether ?= is appropriate or whether a separate user-facing override variable is needed.
Proposed fix
For CONTRIB_TESTDB / REGRESS_DBNAME specifically, one approach:
PGXNTOOL_REGRESS_DBNAME ?= $(or $(PGXN),regression)_$(REGRESS_DBHASH)
# ... after include $(PGXS) ...
CONTRIB_TESTDB = $(PGXNTOOL_REGRESS_DBNAME)
This preserves the auto-computed default while giving users a clean override point that won't be clobbered by PGXS.
More broadly, the fix should establish a convention: pgxntool should never use plain =/:= for a variable a user might reasonably want to control, unless there is a documented, tested override mechanism for it.
Problem
Some pgxntool variables are set with plain
=afterinclude $(PGXS)inbase.mk, which means there is no way for a user to override them regardless of where they set values in their own Makefile. The most impactful case:where
REGRESS_DBNAMEis computed as:and
REGRESS_DBHASHis a hash of$(CURDIR). The result is a database name likecat_tools_dd113— automatically derived, with no supported way to specify a different name.Why this matters
?=pattern works for variables set before PGXS is included, but once PGXS runs and pgxntool reassigns with=, any prior user setting is silently clobbered.PGXNTOOL_NO_PGXS_INCLUDE=1is the only current escape hatch, but it disables all of PGXS — a sledgehammer for what should be a simple knob.Scope
This is a specific instance of a more general pattern: any variable that pgxntool sets with
=or:=afterinclude $(PGXS)is effectively non-overridable. A systematic review of post-PGXS assignments should identify all such cases and decide for each whether?=is appropriate or whether a separate user-facing override variable is needed.Proposed fix
For
CONTRIB_TESTDB/REGRESS_DBNAMEspecifically, one approach:This preserves the auto-computed default while giving users a clean override point that won't be clobbered by PGXS.
More broadly, the fix should establish a convention: pgxntool should never use plain
=/:=for a variable a user might reasonably want to control, unless there is a documented, tested override mechanism for it.