Skip to content

Overview

pg_relay_notifier_utl_mail is a separate, optional PostgreSQL extension. It exists for exactly one reason: so that PL/SQL migrated from Oracle and calling UTL_MAIL.SEND(...) / UTL_MAIL.SEND_ATTACH_RAW(...) / UTL_MAIL.SEND_ATTACH_VARCHAR2(...) can keep calling those names, in that schema, with those exact parameter names and order, unmodified.

It has no functionality of its own. Every utl_mail.* function is a pure passthrough onto pg_relay_notifier's own send_mail() / send_mail_attach_raw() / send_mail_attach_text() — nothing is reimplemented, and there's no separate delivery path, no separate queue, no separate anything. If you don't specifically need the literal Oracle schema/function names, you don't need this extension at all — pg_relay_notifier's own UTL_MAIL-shaped functions (same argument shapes, its own names) are covered in the User Guide and require nothing extra to install.

Why this is a separate extension

Three structural options existed for this: bolt it onto the core extension's own SQL, build it as its own repository, or build it as a second, small, independently-versioned extension living alongside pg_relay_notifier. The last is what shipped, because:

  • Not bolted onto the core extension — that would force an Oracle-migration-specific compatibility layer onto every installer, and mix an audience-specific dialect into the core product's own test/CI/versioning story.
  • Not its own repository — it has zero functionality of its own (every utl_mail.* call is a pure passthrough to functions that already exist and already mirror UTL_MAIL's argument shapes). A separate repository would mean separate release tags, separate CI, and separate version-compatibility tracking against pg_relay_notifier's own function signatures — real coordination overhead for what is, correctly built, a small, self-contained shim.

What you get

  • The literal utl_mail schema, with send, send_attach_raw, send_attach_varchar2 — see the function-mapping pages for the argument-by-argument correspondence with Oracle's real, documented signatures.
  • Automatic resolution of the one thing UTL_MAIL genuinely can't express — a connection endpoint — via a two-tier options fallback. See Default Profile Resolution.
  • The same delivery guarantees as everything else built on pg_relay_notifier: durable, at-least-once, retried, tracked. See the note on synchronous-vs-queued semantics in Behavioural Differences from Oracle — this is the one place migrated code needs to actually think about the difference.

Where to start