The Oracle UTL_MAIL-Style Calls

Three functions, built into the core extension, mirror Oracle's UTL_MAIL package argument-for-argument: comma/semicolon-separated recipient strings, a single body routed by MIME type, and — on the two attach variants — one attachment.

SELECT pgrelay_notifier.send_mail('mailer',
    'a@example.com, b@example.com', 'Subject', 'The message body');

SELECT pgrelay_notifier.send_mail_attach_raw('mailer', 'a@example.com',
    'Subject', 'Body', p_attachment => $bytes$, p_att_filename => 'data.bin');

SELECT pgrelay_notifier.send_mail_attach_text('mailer', 'a@example.com',
    'Subject', 'Body', p_attachment => 'attached text');

Recipient lists are split on comma or semicolon, matching Oracle's own convention. mime_type containing html routes the body to body_html; anything else routes to body_text. Priority defaults follow Oracle's own scale (1 highest – 5 lowest).

Is this what you need, or do you need the literal UTL_MAIL schema?

These three functions are pg_relay_notifier's own functions, named send_mail/send_mail_attach_raw/send_mail_attach_text — a UTL_MAIL-shaped API for new code, or for a hand-adapted migration where you're happy to change UTL_MAIL.SEND(...) to pgrelay_notifier.send_mail(...) in the source.

If your PL/SQL genuinely calls UTL_MAIL.SEND(...) / UTL_MAIL.SEND_ATTACH_RAW(...) / UTL_MAIL.SEND_ATTACH_VARCHAR2(...) and needs that to run completely unmodified — same schema name, same function names, same parameter names and order as Oracle — install the separate, optional pg_relay_notifier_utl_mail extension instead. It provides a literal utl_mail schema and delegates to these same three functions underneath; nothing is reimplemented.

See the UTL_MAIL Compatibility book for the full argument-by-argument mapping against Oracle's real documented signatures.

---