Lenguajes de procedimiento PostgreSQL: diferencias entre PL / pgSQL y SQL

20

¿Alguien puede resumir las diferencias entre:

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

y

http://www.postgresql.org/docs/9.1/static/plpgsql.html

?

Puntos principales:

  • diferencias conceptuales
  • dado un problema familiar, conveniencia de uso
  • problemas politicos
Gismo Ranas
fuente
1
En primer lugar, las funciones de SQL (también conocido como lenguaje de consulta) no incluyen ninguno de los lenguajes de procedimiento de PostgreSQL. En segundo lugar, ya has encontrado la mejor fuente donde uno puede encontrar las respuestas a sus preguntas (con la excepción de la última - ¿Qué es exactamente lo youmean por 'cuestiones políticas')
Dezso
Pedí resumir todos los problemas principales, no necesariamente usando la documentación que pegué, sino también usando impresiones personales. Esos enlaces están ahí solo para asegurarse de que todos entiendan de qué se trata la pregunta.
Gismo Ranas
No lo tome como un asalto, pero una vez que los haya leído, puede resumirlo usted mismo :) De lo contrario, su pregunta es un poco amplia, pero con un poco de tiempo trataré de reunir algunas ideas.
dezso
1
No descuides los otros lenguajes de procedimiento. En particular, PL / Perl es extremadamente útil para áreas donde PL / PgSQL es demasiado limitado; PL / Pythonu hace el trabajo si prefiere Python pero no ofrece un modelo de seguridad como PL / Perl. También hay PL / V8 (JavaScript) como complemento.
Craig Ringer
1
Hola cataldo: me gustaría darte la bienvenida al sitio, ya que esta es tu primera pregunta aquí. Gracias por publicar y espero que te quedes.
Jack Douglas

Respuestas:

27

Las funciones PL / PgSQL y SQL simple son parte de un conjunto de herramientas más grande y deben verse en ese contexto. Tiendo a pensarlo en términos de una escala ascendente de potencia combinada con la complejidad y el costo ascendentes, donde debería usar la herramienta más simple que hará bien el trabajo:

  • Use vistas siempre que sea posible
  • Cuando una vista no es adecuada, use una función SQL
  • Cuando una función SQL no es adecuada, use PL / PgSQL.
  • Donde PL / PgSQL es demasiado limitado o no lo suficientemente expresivo, use PL / Perl, PL / Python, PL / V8, PL / Java, o lo que sea que prefiera
  • ... y donde ningún PL hará el trabajo, use un programa externo y posiblemente LISTENy NOTIFYpara hablar con él.

Con frecuencia, una vista es suficiente cuando cree que se necesita una función. Incluso si es extremadamente costoso para SELECTtoda la vista, las WHEREcláusulas en la consulta que hacen referencia a la vista generalmente se introducen en la vista y pueden generar planes de consulta muy diferentes. A menudo he tenido grandes mejoras de rendimiento al convertir funciones SQL en vistas.

El momento principal en el que encuentra que no puede usar una vista y debe considerar una función SQL es cuando:

  • WHERESe necesitan parámetros que no se puedan expresar como cláusulas simples , como un parámetro dentro de una WITHexpresión
  • Desea una barrera de seguridad mediante una SECURITY DEFINERfunción, y las security_barriervistas en PostgreSQL 9.2 y superiores no son suficientes para sus necesidades;
  • Necesita parámetros que el optimizador no empuje hacia abajo en las subcláusulas de una vista y desea controlarlo más directamente; o
  • Hay muchos parámetros o hay muchas repeticiones de los parámetros, por lo que no es práctico escribir la consulta como una vista.

Para la mayoría de esas tareas, una función SQL simple funciona bien y, a menudo, es más fácil de leer que PL / PgSQL. Las funciones SQL declaradas STABLEo IMMUTABLE(y no también declaradas STRICTo SECURITY DEFINER) también se pueden incluir en la instrucción de llamada. Eso elimina la sobrecarga de la llamada a la función y, a veces, también puede generar grandes beneficios de rendimiento cuando el optimizador empuja una condición WHERE en la función de llamada hacia la función SQL. Utilice las funciones de SQL siempre que sean suficientes para la tarea.

El momento principal en que las funciones de SQL no harán el trabajo es cuando necesita mucha lógica. Si / luego / otras operaciones que no puede expresar como CASEdeclaraciones, mucha reutilización de los resultados calculados, la creación de valores a partir de fragmentos, manejo de errores, etc. PL / PgSQL es útil entonces. Elija PL / PgSQL cuando no pueda usar las funciones de SQL o no encajen bien, como por ejemplo:

  • SQL dinámico y DDL dinámico a través de la EXECUTEdeclaración
  • Cuando desee RAISEerrores / advertencias para los registros o el cliente
  • Cuando necesite manejo de excepciones: puede atrapar y manejar errores con EXCEPTIONbloques en lugar de hacer que toda la transacción finalice en caso de error
  • Lógica condicional compleja que no encaja CASE ... WHENmuy bien
  • Gran cantidad de reutilización de valores calculados en los que no puede encajar WITHy CTE
  • Construyendo registros dinámicos
  • Debe realizar una acción después de generar el conjunto de resultados.

Con expresiones de tabla comunes (CTE), especialmente CTE de escritura y WITH RECURSIVEencuentro que uso PL / PgSQL mucho menos de lo que solía porque SQL es mucho más expresivo y poderoso. Utilizo vistas y funciones SQL simples mucho más ahora. Vale la pena recordar que las funciones SQL simples pueden contener más de una declaración; La última declaración es el resultado de la función.

Craig Ringer
fuente
¡Muy bien dicho! (aunque virtual +1 adicional por mencionar CTE grabables)
dezso
Esta respuesta también explica por qué algunas funciones necesitan una valla de optimización .
Eonil
8

plpgsqles un lenguaje procesal completo, con variables, construcciones en bucle, etc. Una SQLfunción es simplemente una subconsulta. Una función de SQL, si se declara STABLEo IMMUTABLEno también declaró STRICT, a menudo puede ser inline en la consulta de llamadas, como si estuviera escrito sobre cada referencia.

kgrittn
fuente