cluster() is not numeric-only, and the error already said so (#827 follow-up)

[OffgridwithJD]

Documentation only. Nothing executes differently. Follow-up to the finding I left on
#827, which I had not filed.

Claiming this so it cannot collide with your bug sweep — it touches only the two
extension scripts, one code comment, and the CHANGELOG.

The defect

COMMENT ON FUNCTION pgcolumnar.vacuum_sorted calls the alternative "the
numeric-only Z-order cluster()". Wrong in both directions.

cluster_type_supported() (src/columnar_vacuum.c) takes boolean, smallint,
integer, bigint, real, double precision, date, timestamp and
timestamptz. Several are not numeric. And numeric itself is absent — NUMERICOID
appears nowhere in the file — so the one type the sentence names is precisely the one
cluster() refuses.

The extension already contradicted it. A rejected column raises:

errhint: Z-order clustering supports integer, date/time, boolean, and
floating-point columns.

A user who trips the gate is told the truth. A user who reads the catalog first is
not. The comment now uses the errhint's own wording, so there is one description of
this rule instead of two that disagree.

This is user-facing: COMMENT ON FUNCTION lands in pg_description and is what
\df+ prints — exactly where someone choosing between vacuum_sorted and
cluster() looks.

Measured, not read

A positive control is included so the deny arms are not vacuous. 20,000-row table,
PG 18:

call	result
vacuum_sorted('np','n') numeric	accepted
vacuum_sorted('np','t') text	accepted
cluster('np','i') int	accepted — control
cluster('np','n') numeric	rejected: column "n" of type numeric cannot be used as a clustering key
cluster('np','t') text	rejected

The error a user gets for numeric refutes the word "numeric-only" on its own.

Why the upgrade script is half the fix, and not optional

native_upgrade_converge hashes obj_description(p.oid,'pg_proc') for every
function in the schema. The 1.0-alpha2 -> 1.0-alpha3 script did not re-issue this
comment, so correcting only the full script makes a fresh install and an upgraded one
disagree — and the suite says so. Run in this order:

arm	native_upgrade_converge
unmodified main	8 of 8 PASSED
full script corrected only	FAILED — both the 1.0-alpha and 1.0-alpha2 paths
+ upgrade script re-issues	8 of 8 PASSED

The middle row is the point: the gate catches the half-fix. Re-issuing in that script
is the established pattern — set_options, expire, parallel_copy and
sort_status already do it there. The upgrade copies the literal verbatim from the
full script, so the two cannot drift.

The third site

The same sentence sat in src/columnar_vacuum.c above pgcolumnar_vacuum_sorted.
That is where the catalog string came from, so it is corrected too. Leaving it would
leave the input to the defect in place.

Left alone deliberately: test/fixtures/pgcolumnar--1.0-alpha{,2}.sql and
pgcolumnar--1.0-alpha--1.0-alpha2.sql are faithful snapshots of what shipped, and
the alpha2->alpha3 re-issue corrects the upgrade path anyway. CHANGELOG.md:2422 is
a historical entry.

Gate

arm	result
preflight, PG 15/16/17/18/19	built 5 of 5, 0 warnings each
matrix PG18	231 ran, 2 skipped, ALL PASSED
matrix PG19	233 ran, 0 skipped, ALL PASSED
docs_style	9 of 9
native_upgrade_converge	8 of 8
harness_selftest	PASS on both arms

Those tallies are identical to main at 808cd46 measured on the same box today,
which is how I know the change is inert.

The first gate run failed, and it is worth recording rather than quietly
re-running: docs_style reported
CHANGELOG.md carries no em or en dash: got [2] want [0]. Both dashes were mine, in
the entry above. The house rule is deliberate and documented in the suite. Fixed
before pushing, so this branch has never been red, but it would have been the first
thing CI told you.

[OffgridwithJD]

Force-pushed: rebased onto main a45b4cf2 and the changelog entry has moved out of
this branch, to the changelog PR.

The reason is worth recording. This branch and the changelog branch both added to the
same ### Fixed section of CHANGELOG.md, from different bases. GitHub reported both
as MERGEABLE/CLEAN, which is true and misleading: it compares each against main
independently and cannot see that they collide with each other. Tested both orders in a
worktree and each one conflicted on the second merge:

order A: changelog then this   ->  CONFLICT: CHANGELOG.md
order B: this then changelog   ->  CONFLICT: CHANGELOG.md

So this branch is now the code change alone: the two SQL scripts and the source comment.
Re-tested after the split, both orders merge cleanly.