Update to latest pgxntool

[jnasbyupgrade]

Summary

• Update pgxntool to latest release
• Update .gitignore from pgxntool template

[jnasbyupgrade]

@claude please review this PR.

[claude]

Claude finished @jnasbyupgrade's task in 5m 2s —— View job

---

Claude's Review of "Update to latest pgxntool"

Todo list:

• Gather context (PR diff vs origin/master, changed files)
• Read repo docs (no project-level CLAUDE.md; only vendored pgxntool/CLAUDE.md, which documents the pgxntool tool itself, not this project)
• Review pgxntool vendor update
• Review count_nulls-specific changes (version bump, control/META, SQL upgrade scripts, tests, new ci.yml)
• Post review

---

Summary

This PR pulls in a large upstream update of the vendored pgxntool/ build tooling and, on top of it, bumps count_nulls to 1.0.0, adds the missing versioned SQL upgrade files to git (per the new .gitignore policy), replaces the old flat-file pgTap helpers with CREATE EXTENSION pgtap, and adds a GitHub Actions CI workflow. Most of the diff (base.mk, meta.mk.sh, setup.sh, pgtle.sh, README, etc.) is vendor code pulled in via the standard "squash pgxntool subtree" process, so I focused review on correctness of that vendored logic as it applies here, plus everything specific to this extension.

Findings

1. Likely bug in pgxntool/base.mk:96 (vendored, but affects this project's build)

GE91		 = $(call test, $(MAJORVER), -ge, 91)
...
ifeq ($($call test, $(MAJORVER), -lt 13), yes)
	REGRESS_OPTS += --load-language=plpgsql
endif

Two problems compared to the correct GE91 pattern one line above:

• $($call test, ...) is malformed — it's missing the parenthesis after $ ($(call ...)), so this does not actually invoke the test macro at all. It expands to garbage/empty, meaning the ifeq is always false and --load-language=plpgsql is never added.
• Even if the call syntax were fixed, the threshold is wrong: MAJORVER is scaled by 10 for PG ≥ 10 (MAJORVER = $1 * 10, e.g. PG13 → 130, PG17 → 170), matching the -ge, 91 convention used for GE91 (9.1 → 91). So comparing against 13 instead of 130 would still never match any real MAJORVER value for PG13 specifically as intended (it'd trivially be true for every version ≥ 10, since e.g. 100 is not -lt 13... actually it'd be no for all PG10+ since 100+ is never -lt 13, so the flag would never apply to modern versions either way).

The likely intended fix: ifeq ($(call test, $(MAJORVER), -lt, 130), yes). Since the new .github/workflows/ci.yml in this PR tests PG 10 through 17 (.github/workflows/ci.yml:6), it'd be worth confirming whether older PG versions in that matrix actually need --load-language=plpgsql for installcheck to pass — as currently written, the flag is never applied to any version. I wasn't able to run make/make test in this sandbox (tool permissions block make -n, pg_config --version, etc. outside an allow-listed make test), so please verify with the actual CI run before merging.
Fix this →

2. .travis.yml is now redundant — the new .github/workflows/ci.yml covers PG 10–17 via pgxn/pgxn-tools, making the old Travis config (.travis.yml) dead weight. Not blocking, just a cleanup opportunity in this or a follow-up PR.

Things that look correct

• Version bump is consistent across count_nulls.control, META.in.json, and META.json (0.9.6 → 1.0.0 for the extension; 0.9.7 → 1.0.0 for the distribution).
• sql/count_nulls--0.9.6--1.0.0.sql is a correct no-op upgrade script, and the full upgrade chain (0.9.0→0.9.2→0.9.5→0.9.6→1.0.0) remains intact.
• The .gitignore change to stop ignoring sql/*--*.sql is properly reflected — sql/count_nulls--0.9.6.sql and sql/count_nulls--1.0.0.sql are now correctly tracked, generated via pgxntool/control.mk.sh (which itself looks correct).
• Replacing the ~9,400-line vendored test/helpers/pgtap-core.sql/pgtap-schema.sql with CREATE EXTENSION IF NOT EXISTS pgtap in pgxntool/test/pgxntool/tap_setup.sql is a solid simplification.
• test/deps.sql correctly instantiates the new template with CREATE EXTENSION count_nulls; inside :schema, and the corresponding test/expected/*.out changes are just whitespace/formatting fixes from the pgTap version bump (indentation of # Subtest: lines) — consistent with the new pgTap loaded via extension rather than raw SQL.
• No obviously risky patterns (no curl|sh, no unsafe eval, no destructive shell ops) in the new vendored scripts (lib.sh, control.mk.sh, update-setup-files.sh, pgtle.sh, safesed).

Note on testing

I was not able to execute make test/pg_config/make -n directly in this sandbox (blocked by tool permission restrictions), so this review is based on static analysis of the diff rather than an actual test run. Recommend confirming the CI matrix in the new ci.yml passes (especially for PG 10–12) before merging, given finding #1 above.