Function Mapping — SEND_ATTACH_RAW

utl_mail.send_attach_raw(...) — the UTL_MAIL.SEND_ATTACH_RAW analogue, for one binary attachment. Oracle's own parameter order differs from SEND — replyto moves to the very end, after all the attachment fields — and this mapping preserves that exact order.

Oracle argument (in order)	Type / default	utl_mail.send_attach_raw
sender … priority	(as SEND)	Same mapping
attachment	RAW, required	attachment bytea — NULL here (Postgres-forced default; see Deviation below) degrades to a plain send with no attachment, rather than raising
att_inline	BOOLEAN DEFAULT TRUE	att_inline — same default
att_mime_type	DEFAULT 'application/octet'	att_mime_type — same default. Kept as Oracle's literal historical value, verbatim, for wire-fidelity — even though it differs from pg_relay_notifier's own send_mail_attach_raw() default of 'application/octet-stream'. See the note below on why this matters.
att_filename	VARCHAR2 DEFAULT NULL	att_filename — NULL falls back to a default filename
replyto	VARCHAR2 DEFAULT NULL	replyto → p_reply_to — note the position, at the very end

Deviation: attachment has a default here, but not in Oracle

Same underlying constraint as message in SEND (see Function Mapping — SEND): Oracle's attachment has no default either, and — like message — can't stay required here once earlier parameters (cc, bcc, subject, message, mime_type, priority) already have defaults. attachment DEFAULT NULL was the only legal PostgreSQL signature. Rather than raising on a NULL attachment (which no legitimately migrated call would ever pass, since Oracle requires it), utl_mail.send_attach_raw() degrades gracefully to an ordinary send() with no attachment.

Why the att_mime_type default matters

Getting this default exactly right — not just "a reasonable-looking value" — was worth verifying against Oracle's primary documentation directly rather than from memory, and it's a good illustration of why: the first pass at confirming it (an automated fetch-and-summarize of the Oracle doc) cross-copied SEND_ATTACH_VARCHAR2's default onto SEND_ATTACH_RAW by mistake, since the two procedures sit next to each other in Oracle's documentation and are otherwise near-identical. A second, more targeted check — reading each procedure's own Parameters table individually rather than the shared syntax box — resolved it. 'application/octet' for SEND_ATTACH_RAW, 'text/plain; charset=us-ascii' for SEND_ATTACH_VARCHAR2 (see Function Mapping — SEND_ATTACH_VARCHAR2) — genuinely different values, both confirmed. A compatibility shim exists to match Oracle's real behaviour exactly; a wrong default here would have been precisely the kind of subtle bug that quietly defeats the whole purpose.

---