Repo: pgxntool
PGXNTOOL_INSTALL_SCHEDULE (base.mk:291) is pure internal plumbing -- the
generated install-schedule file path, assigned with plain = (not ?= or
the validate/override pattern in lib.sh), never meant for user override.
Other internal-only override points use a leading underscore instead of the
PGXNTOOL_ prefix specifically so the name itself signals "not part of the
user-facing surface" -- e.g. _CHECK_STALE_EXPECTED_SCRIPT (base.mk:240,
see the comment at base.mk:221). PGXNTOOL_INSTALL_SCHEDULE doesn't follow
that convention, so it reads like a plausible user override point by name
alone, even though it isn't designed to be one.
Found during 2.3.0 release-prep API-documentation review (comprehensive
review pass, ambiguous/naming-consistency finding).
Suggested fix: rename to _INSTALL_SCHEDULE (dropping the PGXNTOOL_
prefix), consistent with _CHECK_STALE_EXPECTED_SCRIPT. This is a rename of
an internal-only variable so should carry no user-facing behavior change,
but should still get a HISTORY.asc mention as a rename since any consumer
project that happened to reference PGXNTOOL_INSTALL_SCHEDULE directly
(unsupported, but possible) would break.
Repo: pgxntool
PGXNTOOL_INSTALL_SCHEDULE(base.mk:291) is pure internal plumbing -- thegenerated install-schedule file path, assigned with plain
=(not?=orthe validate/override pattern in
lib.sh), never meant for user override.Other internal-only override points use a leading underscore instead of the
PGXNTOOL_prefix specifically so the name itself signals "not part of theuser-facing surface" -- e.g.
_CHECK_STALE_EXPECTED_SCRIPT(base.mk:240,see the comment at
base.mk:221).PGXNTOOL_INSTALL_SCHEDULEdoesn't followthat convention, so it reads like a plausible user override point by name
alone, even though it isn't designed to be one.
Found during 2.3.0 release-prep API-documentation review (comprehensive
review pass, ambiguous/naming-consistency finding).
Suggested fix: rename to
_INSTALL_SCHEDULE(dropping thePGXNTOOL_prefix), consistent with
_CHECK_STALE_EXPECTED_SCRIPT. This is a rename ofan internal-only variable so should carry no user-facing behavior change,
but should still get a HISTORY.asc mention as a rename since any consumer
project that happened to reference
PGXNTOOL_INSTALL_SCHEDULEdirectly(unsupported, but possible) would break.