Différence entre le langage sql et le langage plpgsql dans les fonctions PostgreSQL

Fonctions SQL

... sont le meilleur choix :

• Pour les requêtes scalaires simples . Pas grand-chose à planifier, mieux vaut économiser les frais généraux.

• Pour un seul (ou très peu) appels par session . Rien à gagner de la mise en cache du plan via des instructions préparées que PL/pgSQL a à offrir. Voir ci-dessous.

• S'ils sont généralement appelés dans le contexte de requêtes plus importantes et sont suffisamment simples pour être inline .

• Par manque d'expérience avec n'importe quel langage procédural comme PL/pgSQL. Beaucoup connaissent bien SQL et c'est à peu près tout ce dont vous avez besoin pour les fonctions SQL. Peu de gens peuvent en dire autant de PL/pgSQL. (Bien que ce soit plutôt simple.)

• Code un peu plus court. Pas de surcharge de bloc.

Fonctions PL/pgSQL

... sont le meilleur choix :

• Lorsque vous avez besoin d'éléments de procédure ou variables qui ne sont pas disponibles dans les fonctions SQL, évidemment.

• Pour tout type de SQL dynamique , où vous construisez et EXECUTE déclarations de manière dynamique. Une attention particulière est nécessaire pour éviter l'injection SQL. Plus de détails :

  • Fonctions Postgres vs requêtes préparées

• Lorsque vous avez des calculs qui peut être réutilisé à plusieurs endroits et un CTE ne peut pas être étiré à cet effet. Dans une fonction SQL, vous n'avez pas de variables et vous seriez obligé de calculer à plusieurs reprises ou d'écrire dans une table. Cette réponse connexe sur dba.SE contient des exemples de code côte à côte pour résoudre le même problème en utilisant une fonction SQL / une fonction plpgsql / une requête avec des CTE :

  • Comment passer un paramètre dans une fonction

Les affectations sont un peu plus chères que dans d'autres langages procéduraux. Adaptez un style de programmation qui n'utilise pas plus d'affectations que nécessaire.

• Lorsqu'une fonction ne peut pas être intégrée et est appelée à plusieurs reprises. Contrairement aux fonctions SQL, les plans de requête peuvent être mis en cache pour toutes les instructions SQL à l'intérieur d'une fonction PL/pgSQL ; ils sont traités comme des déclarations préparées , le plan est mis en cache pour les appels répétés au sein de la même session (si Postgres s'attend à ce que le plan mis en cache (générique) fonctionne mieux que la replanification à chaque fois. C'est la raison pour laquelle les fonctions PL/pgSQL sont généralement plus rapides après les deux premiers appels dans de tels cas.

  Voici un fil de discussion sur pgsql-performance discutant de certains de ces éléments :

  • Re : les fonctions pl/pgsql sont plus performantes que celles de sql ?

• Lorsque vous devez intercepter les erreurs .

• Pour les fonctions de déclenchement .

• Lors de l'inclusion d'instructions DDL, la modification d'objets ou la modification de catalogues système de quelque manière que ce soit pertinente pour les commandes suivantes - car toutes les instructions dans les fonctions SQL sont analysées en même temps tandis que les fonctions PL/pgSQL planifient et exécutent chaque instruction de manière séquentielle (comme une instruction préparée). Voir :

  • Pourquoi les fonctions PL/pgSQL peuvent-elles avoir des effets secondaires, alors que les fonctions SQL n'en ont pas ?

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