Inactivating a Check

There is no separate "retire" or "remove" function — the update function is the only way to modify an existing check, including inactivating it, through its active/inactive parameter (which defaults to active). Since updating a check is a full replace, not a partial patch, re-supply every field, exactly as for any other call to it:

SELECT pghf.update_check(
    p_check_id       => 'X01-001',
    p_check_name     => 'Tables over 50GB',
    p_routine        => 'pghf.chk_custom_huge_tables(uuid)'::regprocedure,
    p_result_type    => 'integer',
    p_rationale      => 'Updated rationale text here.',
    p_result_unit    => 'count',
    p_numeric_direction => 'lower_is_better',
    p_perfect_value  => '0'::jsonb,
    p_is_builtin     => false,
    p_description    => 'Flags any table exceeding 50GB total size.',
    p_is_active      => false,
    p_retired_reason => 'no longer needed'
);

Passing false for the active flag records the check as retired (with a timestamp and your given reason), excludes it from the collection engine's normal run, and removes it from every suite it belonged to. Past raw results are left untouched — they're historical data. Calling the update function again for the same check with the active flag set back to true (the default) reactivates it — the row still exists the whole time, just inactivated in the meantime; creating a new check would fail here, since that only ever targets a check ID that doesn't already exist. Reactivating (or any other update that leaves a check active) raises an error if the check's namespace or category has since been inactivated — see Inactivating a Namespace or Category in the User Guide — but inactivating a check itself is exempt from that guard and always works, so you can inactivate the checks in a namespace or category on your way to inactivating it too.

Continue to Testing a Check in Isolation.