Cleaning Up (Optional)¶

To remove everything created in this worked example:

-- Drop triggers first (they depend on the trigger functions)
DROP TRIGGER records_after_insert      ON records;
DROP TRIGGER records_after_update      ON records;
DROP TRIGGER records_json_after_insert ON records_json;
DROP TRIGGER records_json_after_update ON records_json;

-- Drop trigger functions and action functions
DROP FUNCTION records_notify();
DROP FUNCTION records_json_notify();
DROP FUNCTION insert_json_record(text);
DROP FUNCTION insert_audit_record(text);
DROP FUNCTION purge_logs(text);

-- Drop tables (order matters — audit and json reference records)
DROP TABLE records_audit;
DROP TABLE records_json;
DROP TABLE records;

-- Unregister channels
SELECT pgrelay.unregister('json_record');
SELECT pgrelay.unregister('audit_action');
SELECT pgrelay.unregister('purge_log');

-- Clear the pg_relay log and dispatched queue rows (optional)
SELECT pgrelay.purge(p_keep_quantity := 0);
SELECT pgrelay.purge_queue(0);

Where to go from here¶

We hope this worked example gave you a feel for how you could use pg_relay in your own database — whether that is event-based work, queued work for later, or event chains (sometimes called "sagas") that let your application code stay quick and return control to the user, while heavier — but equally important — work runs separately, with every step fully logged, retrievable, available to your monitoring tools, and purgeable whenever you choose.

From here:

Go back to the User Guide for a topic-by-topic reference.
Read the Technical Guide for architecture, security, and the full function reference.
If your database runs on a managed cloud provider, see Cloud Setup.