Resetting to Defaults

The seeding function that runs automatically once at the end of installation is completely safe to call again yourself at any later time — a superuser always can, and you can grant that permission explicitly to another role if you'd like them to as well:

SELECT pghf.seed_data();
-- NOTICE:  pghf.seed_data(): namespace, 15 categories, 165 checks, 1 suites, 41 thresholds upserted.

(One suite is reported here because the Spock extension isn't installed on this particular server — it would be two if it were; see Using the Seed Catalog.)

Running it upserts, in order: the built-in namespace, its 15 categories, all 165 built-in checks, the ready-made suites, and their default thresholds.

Preserved across every call: whether a namespace or category has been marked active or inactive, and whether a check has been retired, along with its retirement reason — an administrator's own activation or retirement choices are never touched by re-seeding.

Not preserved: everything else — a check's display name, its backing function, its rationale, and its default threshold values all reset to whatever your currently installed version of the framework ships. That's the entire point of "reset to defaults": a check-level default threshold you'd edited resets on the next call, but a per-suite override is never touched by the seeding function at all, since it only ever knows about the default set.

This is also the exact mechanism a future version of the framework will use to deliver fixes, improvements, or new checks: the seeding function's own definition gets revised in a new release, and re-running it — or simply upgrading the extension, which re-runs it for you automatically — picks up the change, with the same upsert-and-preserve behaviour either way. Any custom checks or thresholds you've registered under your own namespace are never touched by this function at all; it only ever writes rows under the built-in PGHF namespace.

Why built-in checks can't be edited directly

Because every built-in check's definition gets reset like this on every re-seed — including automatically, the moment a future version is installed — the ordinary update function refuses outright to let you edit a built-in check's definition in the first place. A hand-edit would simply be thrown away, silently, the next time re-seeding happens; refusing the edit immediately turns that into an obvious error today, instead of a surprise weeks or months later.

This restriction only covers a check's actual definition. You can always activate or inactivate any built-in check regardless (see Inactivating a Check in the Adding Your Own Checks book), and setting a threshold still works directly against any check, built-in ones included, since a threshold is your own deployment's tuning, not part of what the check fundamentally is.

If you want your own variant of a built-in check, copying it is the way. Cloning a built-in check into your own namespace gives you a completely ordinary check with no such lock on it at all — see Copying an Existing Check.

Checks with an extension prerequisite

Five of the 165 built-in checks are backed by a function that has a hard dependency on some other PostgreSQL extension being installed on the same server — without it, the check has no data source at all, not merely a reduced one. The seeding function checks for each of these extensions before registering the check that depends on it, and simply skips registering it — with an explanatory notice — if the extension isn't there:

NOTICE:  seed_data(): skipping PGHF07-007 (amcheck index verification) — amcheck extension is not installed on this node. Run CREATE EXTENSION amcheck; then call pghf.seed_data() again to register this check.

A skipped check like this simply doesn't exist in the catalog yet at all — it isn't present-but-marked-skipped, it's just absent — until its prerequisite is met. Since every write the seeding function makes is already an upsert, turning one of these checks on later needs no special command: install the extension, then re-run the seeding function, and that call registers the check and adds it to every suite that call builds. Uninstalling the extension again afterwards does not retroactively remove or inactivate an already-registered check — the seeding function only ever adds or updates, never deletes — it simply reverts to permanently reporting itself as skipped at runtime from then on, exactly as if the extension had never been installed.

This is a different, narrower thing from the ordinary runtime "skipped" result every check already reports for a missing prerequisite of its own — that check-level safeguard still exists and still fires regardless. The catalog-level gate described here only decides whether the check gets registered in the first place. A handful of checks whose entire purpose is reporting whether some other extension is installed at all are deliberately not gated this way, since for those, the extension's absence is the data point, not a reason to skip reporting it.

Continue to Creating Your Own Checks and Thresholds.