Installation

pgrelay.schedule requires pg_relay's extension to already be installed — it adds its objects to the pgrelay schema, which the extension owns:

CREATE EXTENSION IF NOT EXISTS pg_relay;

Then, as a superuser, from the schedule/ folder in the repository:

psql -v ON_ERROR_STOP=1 -f install.sql

That's it — no configuration, no seed data. install.sql creates the pgrelay.schedule_type composite type, the validating pgrelay.schedule domain, and about twenty-five functions (constructors, evaluators, parsers).

Upgrading

install.sql is always safe to re-run — including to pick up a newer version, such as when the day_times mode was added. It detects what's already installed and upgrades in place; it never drops the type, the domain, or anything a table you own depends on. Just run it again:

psql -v ON_ERROR_STOP=1 -f install.sql

This wasn't always true

Older versions of install.sql dropped and rebuilt the type unconditionally, which destroyed any table's data on a re-run. If you're on a version that old, upgrade install.sql itself first. See schedule/VERIFICATION.md in the repository if you want the full history.

Removing it

psql -v ON_ERROR_STOP=1 -f uninstall.sql

This removes exactly the objects install.sql added — it never touches pgrelay's own schema or any of pg_relay's own tables and functions. It's safe to run even if you've never installed pgrelay.schedule in that database (everything is DROP ... IF EXISTS).

If you have your own tables using pgrelay.schedule

uninstall.sql refuses to run by default if any table column anywhere in the database still uses pgrelay.schedule, pgrelay.schedule_type, or either's array type — it names every offending column and stops, rather than silently cascading through your data. Migrate or drop those columns first, or accept the data loss explicitly:

psql -v ON_ERROR_STOP=1 -v force_cascade=1 -f uninstall.sql

Version support

Whatever version of PostgreSQL pg_relay itself requires — see Platform Support in the Technical Guide. In practice this has been tested directly, alongside a real pg_relay 1.1 install, against PostgreSQL 14 through 18.

Granting access

Every function here is a shared utility meant for any pg_relay-related application to call, so install.sql deliberately leaves PostgreSQL's default grant in place — EXECUTE is available to PUBLIC, same as pgrelay.notify() itself. If your database policy requires tighter control, revoke and grant explicitly to the roles that need it:

REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA pgrelay FROM PUBLIC;  -- careful: this is schema-wide
GRANT EXECUTE ON FUNCTION pgrelay.weekdays(text) TO my_app_role;
-- ... repeat per function your application actually calls

---

Continue to The Five Modes and Fields.