Une nouvelle transaction démarre avec les caractéristiques de transaction avec leurs valeurs par défaut, comme le niveau d'isolation. Dans le cas où les transactions sont validées à l'intérieur d'une boucle, on peut désirer qu'une transaction démarre automatiquement avec les mêmes caractéristiques que la précédente. Les commandes COMMIT AND CHAIN et ROLLBACK AND CHAIN font cela.

Dans les procédures appelées par la commande CALL ainsi que dans les blocs de code anonymes (commande DO), il est possible de terminer les transactions en utilisant les commandes COMMIT et ROLLBACK. Une nouvelle transaction est démarrée automatiquement après qu'une transaction ait été terminée en utilisant ces commandes, donc il n'existe pas de commande START TRANSACTION. (Notez que BEGIN et END ont une signification différente dans PL/pgSQL.)

Voici un exemple simple :

CREATE PROCEDURE transaction_test1()
LANGUAGE plpgsql
AS $$
BEGIN
    FOR i IN 0..9 LOOP
        INSERT INTO test1 (a) VALUES (i);
        IF i % 2 = 0 THEN
            COMMIT;
        ELSE
            ROLLBACK;
        END IF;
    END LOOP;
END
$$;

CALL transaction_test1();
   

Le contrôle des transactions est seulement possible dans les appels à CALL et DO à partir du plus haut niveau ou dans les appels imbriqués à CALL ou DO sans autre commande. Par exemple, si la pile d'appel est CALL proc1() → CALL proc2() → CALL proc3(), alors la deuxième et la troisième procédures peuvent exécuter les actions de contrôle de transaction. Mais si la pile d'appel est CALL proc1() → SELECT func2() → CALL proc3(), alors la dernière procédure ne peut pas faire de contrôle de transactions à cause du SELECT.

Des considérations spéciales s'appliquent aux boucles de curseur. Considérez cet exemple :

CREATE PROCEDURE transaction_test2()
LANGUAGE plpgsql
AS $$
DECLARE
    r RECORD;
BEGIN
    FOR r IN SELECT * FROM test2 ORDER BY x LOOP
        INSERT INTO test1 (a) VALUES (r.x);
        COMMIT;
    END LOOP;
END;
$$;

CALL transaction_test2();
   

Habituellement, les curseurs sont automatiquement fermés au moment de la validation de la transaction. Néanmoins, un curseur créé dans une boucle comme celle-ci est automatiquement converti en un curseur maintenable par le premier COMMIT ou ROLLBACK. Ceci signifie que le curseur est complètement évalué au premier COMMIT ou ROLLBACK plutôt que ligne par ligne. Le curseur est toujours automatiquement supprimé après la boucle, donc c'est pratiquement invisible pour l'utilisateur.

Les commandes de transaction ne sont pas autorisées dans les boucles de curseur exécutés par des commandes qui ne sont pas en lecture seule (par exemple UPDATE ... RETURNING).

Une transaction ne peut pas être terminée dans un bloc contenant un gestionnaire d'exceptions.