The Default Profile

Every function that takes p_profile — compose(), and everything built on it (send(), send_mail(), and the two attachment variants) — requires the argument, but callers may pass NULL (or an empty string) instead of a real profile name, and it falls back to a database-wide default:

SELECT pgrelay.set_option('pg_relay_notifier.default_profile', 'my_smtp_profile');

If neither an explicit p_profile nor this option is set, compose() raises a clear error naming the option, rather than guessing.

Setting it

set_option/get_option belong to pg_relay, not this extension — they're part of pg_relay's generic key/value options store (pgrelay.options), shared across every pg_relay-based application. Setting or reading them requires a role holding pgrelay.grant_user() (or superuser); it isn't part of pg_relay_notifier's own grant_sender()/grant_admin() helpers, since the underlying functions aren't pg_relay_notifier's to grant.

-- read it back
SELECT pgrelay.get_option('pg_relay_notifier.default_profile');

Why this exists

The obvious case is convenience — application code that only ever uses one profile doesn't need to hardcode its name everywhere. The less obvious case is the UTL_MAIL Compatibility extension: Oracle's UTL_MAIL package has no argument for a connection endpoint at all (it takes one fixed value from the instance-wide smtp_out_server parameter), so migrated code calling UTL_MAIL.SEND(...) has no way to name a profile even if it wanted to. The default-profile option is what makes that migration path work — utl_mail.send() always resolves a profile through it (with one more, extension-specific option layered in front — see the UTL_MAIL book for the full two-tier resolution).

---