Skip to content

Managing Notifications

Listing what's registered

-- everything applicable to one check: its own, its category's, and global
SELECT * FROM pghf.list_notifications(p_check_id => 'PGHF11-009');

-- only its active ones
SELECT * FROM pghf.list_notifications(p_check_id => 'PGHF11-009', p_only_active => true);

-- everything registered
SELECT * FROM pghf.list_notifications();

-- one notification by id — raises if it doesn't exist
SELECT * FROM pghf.get_notification(<notification_id>);

pghf.check_notifications has open read access like every other catalog table, but the functions save you the check-ID-to-internal-identity lookup and raise a clear error for a missing check or id instead of returning nothing. list_notifications(p_check_id => ...) returns everything applicable to that check — check-, category-, and global-scoped — exactly what the dispatcher would consider.

Updating, and activating/inactivating

SELECT pghf.update_notification(
    p_notification_id, p_notification_name, p_delivery_kind, p_is_active,
    p_trigger_mode => ..., p_severities => ...,  -- or p_min_severity
    p_channel_name => ..., p_routine => ..., p_function_args => ...,
    p_cooldown_minutes => ..., p_run_sequence => ...
);

A full replace of every field except scope (which is immutable — delete and re-create to re-scope), the same convention update_check() uses: re-supply everything, not just what changed. p_is_active is how you activate or inactivate — there is no separate toggle. last_fired_at (the cooldown clock) is engine-owned and untouched, so an update never resets a cooldown.

-- stage a notification, dormant, before its consumer is ready
SELECT pghf.create_notification('x01 pager', 'notify', p_check_id => 'X01-001',
    p_min_severity => 'critical', p_channel_name => 'x01_pager', p_is_active => false);

-- ... later, once the consumer is confirmed ...
SELECT pghf.update_notification(<id>, 'x01 pager', 'notify', true,
    p_min_severity => 'critical', p_channel_name => 'x01_pager');

For on_change: activating a previously-inactive notification does not retroactively fire it just because the check is already in the set — transition detection only looks at the check's own evaluation history, so it fires on the next genuine transition, not immediately. (An on_state notification, by contrast, simply starts firing on the next in-set evaluation, since it has no transition to miss.)

Creating or updating raises if the target's namespace/category has been inactivated — the same guard as creating a check or setting a threshold.

Deleting

SELECT pghf.delete_notification(<notification_id>);

Permanent — there's no soft-retire (use p_is_active => false to keep the configuration). Already-journalled firings stay in pghf.notification_log. Unlike create/update, delete is not blocked by an inactivated namespace/category, so cleanup stays possible while winding something down.

Continue to Permission Model.