Profile Defaults¶
Three kinds of default reduce how much you need to pass on every call.
Sender and Reply-To defaults¶
A profile can carry a default send_from and reply_to, set by your DBA. If you omit p_sender/p_reply_to on a compose or send call, the profile's defaults apply; if the profile has none configured either, the connection's own address is used for From, and no Reply-To header is sent at all.
-- profile 'mailer' has send_from = 'noreply@example.com' configured
SELECT pgrelay_notifier.send('mailer', ARRAY['a@example.com'], 'Hi', 'body');
-- → From: noreply@example.com (the profile default, since p_sender was omitted)
SELECT pgrelay_notifier.send('mailer', ARRAY['a@example.com'], 'Hi', 'body',
p_sender := 'support@example.com');
-- → From: support@example.com (your explicit value always wins)
Precedence is always: your explicit argument, then the profile's default, then the connection's own address (From only — there's no connection-level Reply-To to fall back to).
Delay default¶
A profile can also carry a default delay, set by your DBA — if configured, a message sent through that profile doesn't dispatch immediately; it waits that many seconds first, giving anyone watching a window to catch a mistake before it actually goes out.
-- profile 'mailer' has delay_seconds = 30 configured
SELECT pgrelay_notifier.send('mailer', ARRAY['a@example.com'], 'Hi', 'body');
-- → sits in the queue for ~30 seconds before the Processor is even allowed to send it
SELECT pgrelay_notifier.send('mailer', ARRAY['a@example.com'], 'Hi', 'body',
p_run_at := now());
-- → your explicit p_run_at always wins: sends immediately regardless of the profile's delay
Most profiles have no delay configured at all (NULL — dispatch is immediate, today's default behavior for every profile that doesn't opt in). Ask your DBA whether the profile you're using has one before relying on "it'll go out right away."
As of pg_relay v1.2, a delay window like this is genuinely cancellable: pg_relay itself provides pgrelay.cancel(p_id) to pull a not-yet-claimed job out of the queue before it sends. That's a pg_relay-level capability, not something pg_relay_notifier exposes directly — see pg_relay's own documentation and ask your DBA whether it's wired up for you.
Paused profiles¶
A send()/dispatch() call can also fail with something like:
That's your DBA putting the profile under a maintenance window — the mail server or tenant itself being unavailable, not a problem with your code or message. compose() still works fine while a profile is paused; only the actual dispatch is rejected. Retry once the window lifts (the error names exactly when), or ask your DBA — see Pausing and Resuming for what they can do about it.
The default profile¶
Every function that takes p_profile accepts NULL (or '') instead of a real profile name. If your DBA has configured a database-wide default via pgrelay.set_option('pg_relay_notifier.default_profile', '<name>'), that's what gets used:
SELECT pgrelay_notifier.send(NULL, ARRAY['a@example.com'], 'Hi', 'body');
-- → uses whatever profile pg_relay_notifier.default_profile points to
If neither an explicit profile nor the default option is set, the call raises a clear error rather than guessing. Configuring the default profile is a DBA task — see The Default Profile.
This is also exactly what the UTL_MAIL compatibility extension relies on: Oracle's UTL_MAIL package has no concept of a profile argument at all, so utl_mail.send(...) always resolves one this way.