test/install/.sql files never get a real diff — their actual output is
written to the same file as their expected output, so a content difference
can never fail the build. Without ON_ERROR_STOP, a hard SQL error was
silently swallowed too, making the file "pass" regardless of what happened.
make test now fails if a test/install/.sql file doesn’t set
ON_ERROR_STOP: it must either include test/pgxntool/psql.sql (which
sets it) or have its own \set ON_ERROR_STOP or \unset ON_ERROR_STOP
command, to any value; \include and \include_relative count as including psql.sql, the same as
\i and \ir; see
PGXNTOOL_ENABLE_TEST_INSTALL_ERROR_STOP_CHECK to disable. Since
test/install/*.out was never really compared against anything, and is
rewritten by every run, it’s now gitignored — stop committing it.
make test was meant to run test-build first and stop if it failed, but
with check-stale-expected enabled (the default) the main suite ran first.
test-build now always runs before installcheck, including a direct
make installcheck, so a broken build — or a stale
test/build/expected/*.out — stops the run before the main suite starts.
Use make results-build to refresh stale test-build output.
make pgtle PGXNTOOL_PGTLE_VERSION=… (and pgtle.sh --pgtle-version) now
errors unless the value is exactly 1.0.0-1.4.0, 1.4.0-1.5.0 or 1.5.0+.
A plain pg_tle version such as 1.5.0 used to be accepted silently,
generating a bogus pg_tle/1.5.0/ directory; the error now names the range
it belongs to (did you mean 1.5.0+?).
Any value other than exactly pgtap silently selected diffs mode, so a
typo like pgTap quietly weakened the make results safeguard. The value
is now case-insensitive, and anything other than pgtap or diffs is a
hard make error.
Explicitly setting PGXNTOOL_ENABLE_TEST_INSTALL=yes now fails when
test/install/ has no SQL files, as documented and matching
PGXNTOOL_ENABLE_TEST_BUILD; it used to silently run nothing.
Several variables that are pure internal plumbing — never designed as user
override points — were named with a bare PGXNTOOL_ prefix, which reads
like a supported override point by name alone. Renamed to signal "internal,
not part of the user-facing surface", matching the existing
CHECK_STALE_EXPECTED_SCRIPT precedent (itself renamed here too, for the
same _PGXNTOOL consistency): PGXNTOOL_BASE_MK_INCLUDED →
_PGXNTOOL_BASE_MK_INCLUDED, PGXNTOOL_CONTROL_FILES →
_PGXNTOOL_CONTROL_FILES, PGXNTOOL_EXTENSIONS → _PGXNTOOL_EXTENSIONS,
PGXNTOOL_INSTALL_SCHEDULE → _PGXNTOOL_INSTALL_SCHEDULE, and
_CHECK_STALE_EXPECTED_SCRIPT → _PGXNTOOL_CHECK_STALE_EXPECTED_SCRIPT.
None of these are documented anywhere as override points, but if you happened
to reference one directly (unsupported, but possible), update to the new
name. The internal check-stale-expected target is likewise renamed to
_check-stale-expected; make test runs it as before.
New target post-tag-version-bump sets each extension’s default_version
to a placeholder (stable by default) after a release, so later make
runs don’t overwrite the released versioned SQL file; see README. New
releasing-with-pgxntool.md is a recommended release checklist. New
tree-is-clean target fails on uncommitted or untracked changes; tag
and post-tag-version-bump depend on it.
test/verify-results unconditionally filesystem-installed the extension
(via PGXS’s install), and installcheck unconditionally auto-installed
the pgtap dependency via pgxn install pgtap --sudo when it wasn’t already
present — with no way to disable either. That defeated "existing mode"
testing, where the extension (and/or pgtap) was deployed some other way,
e.g. registered via pg_tle instead of the filesystem: calling test or
verify-results would silently filesystem-install as a side effect,
undermining the point of proving the other deployment path works.
PGXNTOOL_ENABLE_FS_INSTALL (default yes) now gates install as a
prerequisite of test/verify-results, and whether installcheck depends
on install. PGXNTOOL_ENABLE_PGXN_INSTALL (default: follows
PGXNTOOL_ENABLE_FS_INSTALL, but can be set independently) gates the pgtap
auto-install. Set either to no to disable.
make print-pgtle prints the generated pg_tle registration SQL for each
extension to stdout, selecting the version directory from the new
PGXNTOOL_PGTLE_TARGET_VERSION variable (an actual pg_tle version, e.g.
1.5.2) or, if unset, the installed pg_tle version. This lets a consumer
build a combined multi-extension install file (e.g.
$(MAKE) -C ../deps/cat_tools print-pgtle >> pgtle-all.sql) without needing
to know the extension name or which pg_tle/ version-range directory
applies. When invoking it recursively for stdout capture, pass
--no-print-directory — otherwise GNU Make’s own Entering
directory/Leaving directory announcements pollute the captured output.
Refreshes test/build/expected/*.out from the last test-build run’s
actual output, mirroring make results for the main suite. Refuses to
bless any file whose actual output contains an ERROR: line, since that
would defeat the point of test-build; skip such a file and bless it by hand
if the error is intentional.
make verify-results used to block make results anytime
regression.diffs existed, which would be the case when there were no
test/expected/ files at all. Switch to actually examining
regression.diffs to determine if tests are broken. Note this is only in
effect when PGXNTOOL_VERIFY_RESULTS_MODE=pgtap.
installcheck needs test/sql/ to exist, but the rule that creates it was
spelled test/sql (no trailing slash), which Make treats as a different
target. A project without that directory got No rule to make target
'test/sql/'; it now gets created like test/expected/ and results/.
Issues fixed in this release: #20, #21, #55, #87, #90, #97, #108, #111, #115, #119
make pgtle’s version-limiting variable was named `PGTLE_VERSION, which
make auto-imports from an identically-named environment variable. That name
is also a natural choice for a CI job’s "which pg_tle to test against" env
var — when one was set, make pgtle/make run-pgtle silently misbehaved
instead of erroring. Renamed to PGXNTOOL_PGTLE_VERSION to avoid the
collision. If you invoke make pgtle PGTLE_VERSION=… directly, update it
to PGXNTOOL_PGTLE_VERSION.
base.mk’s `DATA wildcard (sql/----.sql) only matched upgrade scripts
(two -- separators), silently skipping historical full-install scripts
like sql/ext—0.9.6.sql (one --) even though these are meant to be
committed to git. make install never placed them in the extension
directory, so CREATE EXTENSION ext VERSION 'x.y.z' failed for any version
older than current. Widened to sql/--*.sql, which matches both.
.IGNORE: installcheck made make treat installcheck as always successful
regardless of pg_regress’s exit status, and `test’s recipe only `cat`ed
`regression.diffs for visibility without checking it. make test now exits
non-zero when regression.diffs is non-empty, after printing it.
Issues fixed in this release: #35, #49, #78, #79, #48
make test now fails if test/expected/.out (or test/build/expected/.out)
has no corresponding test/sql/.sql (or test/build/.sql). If your project
has genuinely stale expected-output files sitting around, make test will
newly fail until they’re removed. pg_regress’s alternate expected-output
files (test_0.out .. test_9.out) are recognized and not flagged as stale.
The old name implied it listed every version file for an extension; it
actually only ever holds the current/most-recent one per extension. If your
Makefile references EXTENSION_VERSION_FILES directly (e.g. to add extra
dependencies to DATA), update it to EXTENSIONCURRENT_VERSIONFILES.
There was no way to tell which pgxntool version a project had embedded via
git subtree short of digging through git history. make pgxntool-version
(and pgxntool/bin/version directly) now prints it, read from the
first line of pgxntool/HISTORY.asc — the same line the release process
stamps with the version number. The line is rejected unless it’s STABLE
or a plain X.Y.Z version (digits only, no pre-release suffixes).
These targets hardcoded the origin remote, silently re-tagging the wrong
repository for maintainers whose origin is a personal fork. Defaults to
origin, so existing behavior is unchanged unless you set it.
base.mk’s `pgtle target never passed the PGTLE_VERSION make variable
through to pgtle.sh --pgtle-version, so it silently generated all pg_tle
version ranges regardless of the value given on the command line.
extract_version_from_filename() required every version segment to start
with a digit, so extensions using a persistent stable pseudo-version
(default_version = 'stable') failed with "Cannot parse version from
filename". Widened to accept any non-empty, ---free version string,
matching how pg_tle itself treats extension versions.
The rule generating sql/<ext>--<version>.sql used a > truncate followed
by a separate >> append, so a rule that fired more than once (e.g.
overlapping make processes) doubled the file’s content. Now uses a single
atomic redirect.
base.mk could end up included twice in one make run (for example, an
extension’s own .mk module includes it in addition to the Makefile’s own
include), which redefined every target and printed overriding-recipe
warnings. A second inclusion is now a harmless no-op.
These scripts guarded the project root with [ -d .git ]. In a linked worktree
.git is a file, not a directory, so the check failed: setup.sh would wrongly
re-run git init, and the sync scripts aborted with "Not in a git repository."
They now detect the repo with git rev-parse --git-dir, which works in both a
normal clone and a worktree.
make results ran verify-results before make test, so it checked stale
regression.diffs from a prior run. Reordered so verify-results always
checks the fresh results.
Without override, the pgxntool_validate_yesno normalization was silently
skipped when these variables were set on the command line.
make pgxntool-sync pointed at the old SSH URL, which fails without
GitHub SSH keys; it now uses https://github.com/Postgres-Extensions/pgxntool.git
over HTTPS (still the release tag). The subtree pull + update-setup-files.sh
logic moved into pgxntool/pgxntool-sync.sh, which the make targets now wrap, so
you can also sync without make by running it directly.
Control file values like default_version = '1.0.0' # comment were parsed
incorrectly — the trailing quote was left in the value due to comment removal
happening after quote stripping. Fixed by removing comments first.
Mac OS uses the (very old) bash 3.2 as the default shell; fix a few compatibility bugs.
PostgreSQL removed .source file processing from pg_regress in PG15.
The input/.source → sql/.sql and output/.source →
expected/.out conversion mechanism no longer functions. All related
variables (TESTSOURCE*), the make_results.sh helper script, and
the special-case logic in make results have been removed. Extensions
that used .source files should convert them to regular test/sql/.sql
and test/expected/.out files using relative paths.
When CREATE EXTENSION fails due to a SQL syntax error, PostgreSQL reports only a cryptic error with limited context. test-build runs your extension SQL directly through pg_regress first, so syntax errors show the exact file, line, and position — cutting debugging time significantly. Place SQL files in test/build/ to enable; auto-detects based on file presence.
Extensions that install dependencies or run expensive setup in every test file pay that cost once per test. test/install runs setup SQL once before the entire test suite, and all regular tests share the resulting database state. This can dramatically speed up test suites that install extensions or load fixtures. Place SQL files in test/install/ to enable; auto-detects based on file presence.
make results now refuses to run when tests are failing (detected via regression.diffs). Prevents accidentally blessing incorrect output as the new expected results. Enabled by default; disable with PGXNTOOL_ENABLE_VERIFY_RESULTS=no.
${ARRAY[@]:-0} is a syntax error in bash 3.2; replaced with ${#ARRAY[@]}.
Shell scripts now use !/usr/bin/env bash.
The unique database naming introduced in 1.1.0 was ineffective because base.mk added --dbname=$(REGRESS_DBNAME) to REGRESS_OPTS while PGXS also appends --dbname=$(CONTRIB_TESTDB). The second --dbname caused pg_regress to create a contrib_regression database that collided across projects. Fixed by overriding CONTRIB_TESTDB after include $(PGXS) instead.
The exception handler for uninstall_extension() now correctly catches
no_data_found (P0002) instead of undefined_object (42704). Empty upgrade
files are now treated as valid no-op upgrades for version bumps. Added
ON_ERROR_STOP=1 to run_pgtle_sql() so psql errors propagate correctly.
Tests now use a unique database name based on the project name and a hash of the current directory. This prevents test conflicts when running tests for multiple projects in parallel.
New update-setup-files.sh script handles merging changes to files initially
copied by setup.sh (.gitignore, test/deps.sql). After running make
pgxntool-sync, the script performs a 3-way merge if both you and pgxntool have
modified the same file, using git’s native conflict markers for resolution.
Prior to this fix, distributions with multiple extensions or extensions with
versions different from the PGXN distribution version were completely broken.
Extension versions are now correctly read from each .control file’s
default_version instead of using META.json’s distribution version.
New make pgtle target generates pg_tle registration SQL for extensions.
Supports pg_tle version ranges (1.0.0-1.4.0, 1.4.0-1.5.0, 1.5.0+) with
appropriate API calls for each range. See README for usage.
The tag and rmtag targets now create/delete git tags instead of branches.
As part of this change, you will want to review the changes to test/deps.sql.
By default, if asciidoctor or asciidoc exists on the system, any files in doc/ that end in .adoc or .asciidoc will be processed to html.
See the README for full details.
If a test input file changes we certainly need to re-run tests.
Paul Norman #3
Having the tap stuff in deps.sql was confusing because it was also loaded by setup.sql. Just let setup.sql handle it, as that’s what most people should probably do. At some point we’ll probably need a way to over-ride this though…
This is necessary because some install targets are generated and would not necessarily be on the filesystem when we installed. This also prevents installing leftover cruft from old versions.