Attachment Limits and Profile Defaults

Every profile carries two enforced limits:

• max_attach_mb — a notification's total attachment payload, in raw MB.
• max_attach_number — attachments per notification.

attach()/attach_text() reject over-limit content in the caller's transaction, naming the profile — not asynchronously, after a delivery attempt has already been burned.

Seeds for new profiles

New profiles copy their starting values from per-transport seeds in profile_defaults, installed as:

Transport	max_attach_mb	max_attach_number
smtp	10	999
m365	3 (Microsoft's fileAttachment limit)	999

Seeds are a starting point only — each profile then owns its own limits independently:

SELECT * FROM pgrelay_notifier.list_profile_defaults();

-- tune a live profile (effective on the next attach)
SELECT pgrelay_notifier.update_profile('mailer', p_max_attach_mb := 25, p_max_attach_number := 50);

-- change the starting point for FUTURE profiles (existing ones untouched)
SELECT pgrelay_notifier.update_profile_defaults('smtp', p_max_attach_mb := 25);

-- or set limits explicitly at creation
SELECT pgrelay_notifier.create_profile('bulk_mailer', 'smtp', '{...}'::jsonb,
    p_max_attach_mb := 50, p_max_attach_number := 10);

The caps count raw stored bytes; base64 encoding adds roughly 37% on the wire, so leave headroom against what the relay actually accepts.

Why profile_defaults survives DROP EXTENSION

This table is deliberately not an extension member. A table whose rows the install seeds and the DBA edits can't round-trip pg_dump/restore as ordinary extension configuration — re-seeded rows would collide with dumped ones. Detaching it from the extension means:

• DBA-edited seeds survive DROP EXTENSION, reinstall, and dump/restore.
• \dx+ pg_relay_notifier does not list it.
• Uninstalling completely means dropping the schema — see Uninstalling and Reinstalling.

---