Profile Defaults

Two 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).

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.

---