Aktualizacja PostgreSQL 12 :jest ograniczone wsparcie dla najwyższego poziomu PROCEDURE s, które mogą wykonywać kontrolę transakcji. Nadal nie można zarządzać transakcjami w zwykłych funkcjach wywoływanych przez SQL, więc poniższe informacje pozostają prawdziwe, z wyjątkiem sytuacji, gdy używane są nowe procedury najwyższego poziomu.
Funkcje są częścią transakcji, z której są wywoływane. Ich efekty są cofane, jeśli transakcja zostanie cofnięta. Ich praca zostaje zatwierdzona, jeśli transakcja zostanie zatwierdzona. Dowolny BEGIN ... EXCEPT bloki w funkcji działają jak (i pod maską) punkty zapisu, takie jak SAVEPOINT i ROLLBACK TO SAVEPOINT Instrukcje SQL.
Funkcja albo powiodła się w całości, albo zakończyła się niepowodzeniem w całości, z wyjątkiem BEGIN ... EXCEPT obsługa błędów. Jeśli błąd zostanie zgłoszony w funkcji i nie zostanie obsłużony, transakcja wywołująca funkcję jest przerywana. Przerwane transakcje nie mogą zatwierdzić, a jeśli próbują zatwierdzić COMMIT jest traktowany jako ROLLBACK , tak samo jak w przypadku innych błędnych transakcji. Obserwuj:
regress=# BEGIN;
BEGIN
regress=# SELECT 1/0;
ERROR: division by zero
regress=# COMMIT;
ROLLBACK
Zobacz, jak transakcja, która jest w stanie błędu z powodu dzielenia przez zero, wycofuje się po COMMIT ?
Jeśli wywołasz funkcję bez wyraźnej transakcji otaczającej, reguły są dokładnie takie same, jak w przypadku każdej innej instrukcji Pg:
BEGIN;
SELECT refresh_materialized_view(name);
COMMIT;
(gdzie COMMIT nie powiedzie się, jeśli SELECT zgłosił błąd).
PostgreSQL nie obsługuje (jeszcze) autonomicznych transakcji w funkcjach, w których procedura/funkcja mogłaby zatwierdzić/wycofać niezależnie od transakcji wywołującej. Można to zasymulować za pomocą nowej sesji przez dblink.
ALE , rzeczy, które nie są transakcyjne lub są niedokładnie transakcyjne, istnieją w PostgreSQL. Jeśli ma zachowanie nietransakcyjne w normalnym BEGIN; do stuff; COMMIT; blok, zachowuje się również nietransakcyjnie w funkcji. Na przykład nextval i setval , TRUNCATE itp.
