See the excellent-as-usual depesz article, and pg-message-queue.
Sending email directly from the database may not be a great idea. What if DNS resolution is slow and everything hangs for 30 seconds then times out? What if your mail server is having a wobbly and takes 5 minutes to accept messages? You’ll get database sessions hung up in your trigger until you’re at max_connections and suddenly you can’t do anything but wait or start manually cancelling transactions.
What I’d recommend is having your trigger NOTIFY a LISTENing helper script that remains permanently running and connected to the DB (but not in a transaction).
All your trigger has to do is INSERT a row into a queue table and send a NOTIFY. Your script gets the NOTIFY message because it has registered to LISTEN for it, examines the queue table, and does the rest.
You can write the helper program in whatever language is convenient; I usually use Python with psycopg2.
That script can send the email based on information it finds in the database. You don’t have to do all the ugly text formatting in PL/PgSQL, you can substitute things into a template in a more powerful scripting language instead, and just fetch the variable data from the database when a NOTIFY comes in.
With this approach your helper can send each message and only then remove the info from the queue table. That way if there are transient problems with your mail system that causes sending to fail, you haven’t lost the info and can continue to attempt to send it until you succeed.
If you really must do this in the database, see PgMail.