Function Mapping — SEND

utl_mail.send(...) — the UTL_MAIL.SEND analogue. Parameter names and order match Oracle's real signature exactly, verified against the Oracle 19c PL/SQL Packages and Types Reference, so migrated PL/SQL using named notation (sender => ..., recipients => ...) translates unmodified.

Oracle argument	Type / default	utl_mail.send
sender	VARCHAR2, required	sender → p_sender
recipients	VARCHAR2, required, comma-separated	recipients → p_recipients
cc	VARCHAR2 DEFAULT NULL	cc → p_cc
bcc	VARCHAR2 DEFAULT NULL	bcc → p_bcc
subject	VARCHAR2 DEFAULT NULL	subject → p_subject
message	VARCHAR2, required	message — defaults to '' here (see Deviation below) → p_message
mime_type	DEFAULT 'text/plain; charset=us-ascii'	mime_type — same default; a type containing html routes to body_html, anything else to body_text
priority	PLS_INTEGER DEFAULT 3	priority — same default (1 highest – 5 lowest); range-checked 1–5
replyto	VARCHAR2 DEFAULT NULL	replyto → p_reply_to
(none — Oracle has no equivalent)	—	Profile resolved automatically — see Default Profile Resolution

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

Oracle's message has no default — it sits at position 6, after several parameters (cc, bcc, subject) that do have defaults. That's legal in Oracle PL/SQL. It is not legal in PostgreSQL, which requires every parameter after the first defaulted one to also have a default — CREATE FUNCTION would simply be rejected otherwise.

message therefore defaults to '' in utl_mail.send(), rather than being required. This is harmless in practice: Oracle enforces message's requiredness at compile time, so every legitimately migrated call already supplies it regardless of what the PostgreSQL signature allows. And an empty or omitted body is accepted anyway on this side — compose() stores a single-space placeholder rather than raising, since a message with no body is a completely ordinary thing to send (see Behavioural Differences from Oracle).

---