Building a Suite by Pattern, Across Namespaces

Suites don't care what namespace or category a check comes from — a suite is just an ordered list of checks, so mixing your own namespace with built-in checks in one suite, in whatever order you like, already works with nothing beyond adding checks one at a time. When you want to add a whole category or namespace at once instead, pghf.add_checks_matching() does that by pattern, with a preview-by-default safety gate:

-- preview only — nothing is added, and an empty match is not an error here
SELECT * FROM pghf.add_checks_matching('my_suite', 'PGHF01-*');
--   check_id  | namespace_code | category_code |       category_name       |    check_name         | catalog_is_active
-- ------------+----------------+---------------+----------------------------+------------------------+-------------------
--  PGHF01-001 | PGHF           | 01            | Connection & Availability  | SSL/TLS enabled        | t
--  ...

-- now actually add them (same pattern, p_show_only => false)
SELECT * FROM pghf.add_checks_matching('my_suite', 'PGHF01-*', false);

-- everything under your own namespace, any category
SELECT * FROM pghf.add_checks_matching('my_suite', 'ACME*', false);

The pattern is either an exact check ID, or a right-anchored wildcard — a single trailing * ('PGHF01-*', 'PGHF*'); a * anywhere else in the pattern is rejected. Preview mode is the default: it matches and returns what it found without touching the suite at all, and an empty match is a perfectly normal (not an error) answer to "what would this pattern catch?" Only actually performing the add raises an error if the pattern matches nothing — since silently doing nothing on a call meant to change the suite is exactly the kind of typo'd-pattern mistake worth catching loudly rather than staying quiet about. It also raises an error on the first match whose namespace or category has been inactivated (see Inactivating a Namespace or Category in the User Guide) — the preview's active-status column tells you that ahead of a real add, so you can activate it first or narrow the pattern.

One sharp edge worth knowing: a check ID has no separator between its namespace and category codes (only between the category and the run number — 'PGHF01-006'), so a namespace code that happens to be a prefix of another namespace's code will over-match — 'PG*' would match both PG and PGHF if you'd registered both. Avoid choosing namespace codes that are prefixes of each other if you plan to pattern-match against them.

Removing checks is symmetric: one function for a single check, another for several by exact check ID in one call — useful, for example, when you bulk-added a whole category and only needed most of it:

SELECT pghf.remove_checks_from_run('my_suite', 'PGHF01-003', 'PGHF01-006');

Like the bulk-add function, this is all-or-nothing per call — if any listed check ID doesn't exist (or isn't actually a member), the whole call raises an error and rolls back, rather than removing some and silently skipping the rest.

Continue to Putting It All Together.