Dlaczego funkcje PL/pgSQL mogą mieć efekt uboczny, a funkcje SQL nie?

Sam pogrubiłeś kluczowe zdanie w instrukcji:

Cała treść funkcji SQL jest analizowana przed wykonaniem którejkolwiek z nich.

Przeczytaj także o etapie parsera w instrukcji.

Składa się z dwóch głównych części:parsera i proces transformacji . Cytując instrukcję:

proces transformacji pobiera drzewo przekazane przez parser jako dane wejściowe i dokonuje interpretacji semantycznej potrzebnej do zrozumienia, do których tabel, funkcji i operatorów odwołuje się zapytanie.

Jeśli funkcja SQL zawiera te polecenia:

CREATE TABLE foo (...);
INSERT INTO foo VALUES(...);

Oba zestawienia planowane są praktycznie w tym samym czasie (w oparciu o tę samą migawkę katalogów systemowych). Stąd INSERT nie widać tabeli "foo" prawdopodobnie utworzonej za pomocą poprzedniego CREATE Komenda. To stwarza jeden z następujących problemów :

Jeśli nie ma innych tabela o nazwie "foo" w Twojej search_patch (jeszcze), Postgres narzeka przy próbie stworzenia funkcja:
```
ERROR:  relation "foo" does not exist
```
Jeśli inna tabela o nazwie „foo” już istnieje w Twojej search_patch (i nie używasz sprzecznych nazw kolumn), Postgres zaplanuje INSERT na podstawie tej wcześniej istniejącej tabeli. Zwykle powoduje to błąd w czasie wykonywania , jeśli jakiekolwiek wartości powodują konflikty w (niewłaściwej!) tabeli. Lub, przy odrobinie szczęścia, może nawet napisać do tej tabeli bez komunikatu o błędzie! Bardzo podstępny błąd.

To nie może się zdarzyć w przypadku PL/pgSQL funkcja, ponieważ traktuje polecenia SQL jak przygotowane instrukcje, planowane i wykonywane sekwencyjnie . Tak więc każda instrukcja może zobaczyć obiekty utworzone w poprzednich instrukcjach.

W konsekwencji instrukcje, które nigdy nie są odwiedzane, nigdy nie są nawet planowane – w przeciwieństwie do funkcji SQL. Plan wykonania instrukcji może być buforowany w ramach tej samej sesji — również w przeciwieństwie do funkcji SQL. Przeczytaj szczegółowe informacje na temat buforowania planu w funkcjach PL/pgSQL w podręczniku tutaj.
Każde podejście ma zalety w niektórych przypadkach użycia. Dalsza lektura:

Różnica między językiem sql a językiem plpgsql w funkcjach PostgreSQL