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

... są lepszym wyborem:

W przypadku prostych zapytań skalarnych . Niewiele do planowania, lepiej oszczędzaj na kosztach.
W przypadku pojedynczych (lub bardzo niewielu) połączeń na sesję . Nic do zyskania z buforowania planu za pomocą przygotowanych instrukcji, które PL/pgSQL ma do zaoferowania. Zobacz poniżej.
Jeśli są zwykle wywoływane w kontekście większych zapytań i są na tyle proste, aby były wbudowane .
Z braku doświadczenia z dowolnym językiem proceduralnym, takim jak PL/pgSQL. Wielu dobrze zna SQL i to wszystko, czego potrzebujesz do funkcji SQL. Niewielu może powiedzieć to samo o PL/pgSQL. (Chociaż to dość proste.)
Nieco krótszy kod. Brak narzutu blokowego.

... są lepszym wyborem:

Gdy potrzebujesz jakichkolwiek elementów proceduralnych lub zmienne które oczywiście nie są dostępne w funkcjach SQL.
Dla każdego rodzaju dynamicznego SQL , gdzie budujesz i EXECUTE wypowiedzi dynamicznie. Należy zachować szczególną ostrożność, aby uniknąć wstrzyknięcia SQL. Więcej szczegółów:
- Funkcje Postgres a przygotowane zapytania
Gdy masz obliczenia które można ponownie wykorzystać w kilku miejscach i CTE nie może być w tym celu rozciągnięte. W funkcji SQL nie masz zmiennych i musiałbyś wielokrotnie wykonywać obliczenia lub zapisywać do tabeli. Ta powiązana odpowiedź na dba.SE zawiera obok siebie przykłady kodu do rozwiązania tego samego problemu za pomocą funkcji SQL / funkcji plpgsql / zapytania z CTE:
- Jak przekazać parametr do funkcji

Zadania są nieco droższe niż w innych językach proceduralnych. Dostosuj styl programowania, który nie używa więcej przypisań niż to konieczne.

Gdy funkcja nie może być wbudowana i jest wywoływana wielokrotnie. W przeciwieństwie do funkcji SQL, plany zapytań mogą być buforowane dla wszystkich instrukcji SQL wewnątrz funkcji PL/pgSQL; są traktowane jak przygotowane zestawienia , plan jest buforowany dla powtarzających się wywołań w ramach tej samej sesji (jeśli Postgres oczekuje, że buforowany (ogólny) plan będzie działał lepiej niż ponowne planowanie za każdym razem. To jest powód, dla którego funkcje PL/pgSQL są zwykle szybsze po kilku pierwszych połączeniach w takich przypadkach.

Oto wątek na temat wydajności pgsql omawiający niektóre z tych elementów:
- Odp.:funkcje pl/pgsql przewyższają funkcje sql?
Kiedy trzeba wyłapać błędy .
Dla funkcji wyzwalania .
W przypadku dołączania instrukcji DDL zmienianie obiektów lub zmienianie katalogów systemowych w jakikolwiek sposób związany z kolejnymi poleceniami - ponieważ wszystkie instrukcje w funkcjach SQL są analizowane jednocześnie, podczas gdy funkcje PL/pgSQL planują i wykonują każdą instrukcję sekwencyjnie (jak przygotowana instrukcja). Zobacz:
- Dlaczego funkcje PL/pgSQL mogą mieć efekt uboczny, a funkcje SQL nie?

Weź również pod uwagę:

Aby faktycznie zwrócić z funkcji PL/pgSQL, możesz napisać:

CREATE FUNCTION f2(istr varchar)
  RETURNS text AS
$func$
BEGIN
   RETURN 'hello! ';  -- defaults to type text anyway
END
$func$ LANGUAGE plpgsql;

Są inne sposoby:

Czy mogę sprawić, by funkcja plpgsql zwróciła liczbę całkowitą bez użycia zmiennej?
Podręcznik „Powrót z funkcji”