SQL функции
... са по-добрият избор:
-
Запрости скаларни заявки . Няма много за планиране, по-добре спестете режийни разходи.
-
За единични (или много малко) обаждания на сесия . Няма какво да спечелите от кеширането на планове чрез подготвени оператори, които PL/pgSQL може да предложи. Вижте по-долу.
-
Ако те обикновено се извикват в контекста на по-големи заявки и са достатъчно прости, за да бъдат вградени .
-
Поради липса на опити с всеки процедурен език като PL/pgSQL. Мнозина познават добре SQL и това е всичко, което ви е необходимо за SQL функциите. Малцина могат да кажат същото за PL/pgSQL. (Въпреки че е доста просто.)
-
Малко по-кратък код. Без блокировка.
PL/pgSQL функции
... са по-добрият избор:
-
Когато имате нужда от някакви процедурни елементи или променливи които не са налични в SQL функциите, очевидно.
-
За всякакъв вид динамичен SQL , където изграждате и
EXECUTEизявления динамично. Необходими са специални грижи, за да се избегне SQL инжектиране. Повече подробности:- Функции на Postgres срещу подготвени заявки
-
Когато имате изчисления които могат да бъдат използвани повторно на няколко места и CTE не може да се разтегне за целта. В SQL функция нямате променливи и ще бъдете принудени да изчислявате многократно или да записвате в таблица. Този свързан отговор на dba.SE има един до друг примери за код за решаване на същия проблем с помощта на SQL функция / функция plpgsql / заявка с CTEs:
- Как да предам параметър във функция
Заданията са малко по-скъпи, отколкото в други процедурни езици. Адаптирайте стил на програмиране, който не използва повече задания, отколкото е необходимо.
-
Когато функция не може да бъде вградена и се извиква многократно. За разлика от SQL функциите, плановете за заявки могат да се кешират за всички SQL изрази в PL/pgSQL функции; те се третират като изготвени изявления , планът се кешира за повтарящи се повиквания в рамките на една и съща сесия (ако Postgres очаква кешираният (генеричен) план да работи по-добре от повторното планиране всеки път. Това е причината функциите PL/pgSQL да са обикновено по-бързи след първите няколко обаждания в такива случаи.
Ето нишка за pgsql-performance, в която се обсъждат някои от тези елементи:
- Re:pl/pgsql функции превъзхождат тези sql?
-
Когато трябва да захващате грешки .
-
Зафункции за задействане .
-
При включване на DDL оператори, променящи обекти или промяна на системни каталози по какъвто и да е начин, свързан с последващи команди - защото всички изрази в SQL функциите се анализират наведнъж, докато функциите PL/pgSQL планират и изпълняват всеки оператор последователно (като подготвен оператор). Вижте:
- Защо функциите PL/pgSQL могат да имат страничен ефект, докато SQL функциите не могат?
Също така имайте предвид:
- Ефективност на PostgreSQL съхранената процедура
За действително връщане от PL/pgSQL функция, можете да напишете:
CREATE FUNCTION f2(istr varchar)
RETURNS text AS
$func$
BEGIN
RETURN 'hello! '; -- defaults to type text anyway
END
$func$ LANGUAGE plpgsql;
Има и други начини:
- Мога ли да накарам функция plpgsql да връща цяло число, без да използвам променлива?
- Ръководството за „Връщане от функция“
