Atualização do PostgreSQL 12 :há suporte limitado para
PROCEDURE de nível superior s que podem fazer o controle de transações. Você ainda não pode gerenciar transações em funções regulares que podem ser chamadas por SQL, portanto, o abaixo permanece verdadeiro, exceto ao usar os novos procedimentos de nível superior. As funções fazem parte da transação da qual são chamadas. Seus efeitos são revertidos se a transação for revertida. O trabalho deles é confirmado se a transação for confirmada. Qualquer
BEGIN ... EXCEPT blocos dentro da função operam como (e sob o capô usam) pontos de salvamento como o SAVEPOINT e ROLLBACK TO SAVEPOINT instruções SQL. A função é bem-sucedida em sua totalidade ou falha em sua totalidade, exceto
BEGIN ... EXCEPT Manipulação de erros. Se um erro for gerado dentro da função e não for tratado, a transação que chama a função será abortada. As transações abortadas não podem ser confirmadas e, se tentarem, COMMIT é tratado como ROLLBACK , o mesmo que para qualquer outra transação com erro. Observar:regress=# BEGIN;
BEGIN
regress=# SELECT 1/0;
ERROR: division by zero
regress=# COMMIT;
ROLLBACK
Veja como a transação, que está no estado de erro devido à divisão zero, é revertida em
COMMIT ? Se você chamar uma função sem uma transação envolvente explícita, as regras são exatamente as mesmas de qualquer outra instrução Pg:
BEGIN;
SELECT refresh_materialized_view(name);
COMMIT;
(onde
COMMIT falhará se o SELECT gerou um erro). O PostgreSQL (ainda) não suporta transações autônomas em funções, onde o procedimento/função pode confirmar/reverter independentemente da transação de chamada. Isso pode ser simulado usando uma nova sessão via dblink.
MAS , coisas que não são transacionais ou são imperfeitamente transacionais existem no PostgreSQL. Se tiver comportamento não transacional em um
BEGIN; do stuff; COMMIT; bloco, ele também tem comportamento não transacional em uma função. Por exemplo, nextval e setval , TRUNCATE , etc 
