Diferencia entre lenguaje sql y lenguaje plpgsql en funciones de PostgreSQL

Funciones SQL

... son la mejor opción:

• Para consultas escalares simples . No hay mucho que planificar, mejor ahorra gastos generales.

• Para llamadas únicas (o muy pocas) por sesión . No se gana nada con el almacenamiento en caché del plan a través de declaraciones preparadas que PL/pgSQL tiene para ofrecer. Ver más abajo.

• Si normalmente se llaman en el contexto de consultas más grandes y son lo suficientemente simples como para ser en línea .

• Por falta de experiencia con cualquier lenguaje procedimental como PL/pgSQL. Muchos conocen bien SQL y eso es todo lo que necesita para las funciones de SQL. Pocos pueden decir lo mismo sobre PL/pgSQL. (Aunque es bastante simple.)

• Un código un poco más corto. Sin sobrecarga de bloques.

Funciones PL/pgSQL

... son la mejor opción:

• Cuando necesite cualquier elemento de procedimiento o variables que no están disponibles en funciones SQL, obviamente.

• Para cualquier tipo de SQL dinámico , donde compila y EXECUTE declaraciones de forma dinámica. Se necesita especial cuidado para evitar la inyección SQL. Más detalles:

  • Funciones de Postgres frente a consultas preparadas

• Cuando tiene cálculos que se puede reutilizar en varios lugares y un CTE no se puede estirar para ese propósito. En una función SQL, no tiene variables y se vería obligado a calcular repetidamente o escribir en una tabla. Esta respuesta relacionada en dba.SE tiene ejemplos de código uno al lado del otro para resolver el mismo problema usando una función SQL/una función plpgsql/una consulta con CTE:

  • Cómo pasar un parámetro a una función

Las asignaciones son algo más caras que en otros lenguajes procesales. Adapte un estilo de programación que no utilice más asignaciones de las necesarias.

• Cuando una función no se puede insertar y se llama repetidamente. A diferencia de las funciones SQL, los planes de consulta se pueden almacenar en caché para todas las sentencias SQL dentro de funciones PL/pgSQL; se tratan como declaraciones preparadas , el plan se almacena en caché para llamadas repetidas dentro de la misma sesión (si Postgres espera que el plan almacenado en caché (genérico) funcione mejor que volver a planificar cada vez. Esa es la razón por la cual las funciones PL/pgSQL son típicamente más rápidas después del primer par de llamadas en tales casos.

  Aquí hay un hilo sobre el rendimiento de pgsql que analiza algunos de estos elementos:

  • Re:funciones pl/pgsql superan a las de sql?

• Cuando necesite atrapar errores .

• Para funciones de activación .

• Al incluir sentencias DDL que cambian objetos o alteran catálogos del sistema de alguna manera relevante para los comandos posteriores, porque todas las sentencias en las funciones SQL se analizan a la vez mientras que las funciones PL/pgSQL planifican y ejecutan cada sentencia secuencialmente (como una sentencia preparada). Ver:

  • ¿Por qué las funciones PL/pgSQL pueden tener efectos secundarios, mientras que las funciones SQL no?

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