PostgreSQL-Verfahrenssprachen - Unterschiede zwischen PL / pgSQL und SQL


20

Kann jemand bitte die Unterschiede zusammenfassen zwischen:

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

und

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

?

Hauptpunkte:

  • konzeptionelle Unterschiede
  • gegeben eine Problemfamilie, Bequemlichkeit der Verwendung
  • politische Probleme

1
Erstens beziehen SQL-Funktionen (auch als Abfragesprache bezeichnet) keine der prozeduralen PostgreSQL-Sprachen ein. Zweitens haben Sie bereits die beste Quelle gefunden, aus der Sie die Antworten auf Ihre Fragen finden können (mit Ausnahme der letzten - was genau verstehen Sie unter "politischen Fragen"?)
6.

Ich bat darum , alle Hauptthemen zusammenzufassen, nicht nur anhand der von mir eingefügten Dokumentation, sondern auch anhand persönlicher Eindrücke. Diese Links sind nur da, um sicherzugehen, dass jeder versteht, worum es bei der Frage geht.
Gismo Ranas

Nehmen Sie es nicht als Angriff, aber wenn Sie diese gelesen haben, können Sie sie selbst zusammenfassen.
Dezso

1
Vernachlässigen Sie nicht die anderen Verfahrenssprachen. Insbesondere PL / Perl ist äußerst nützlich für Bereiche, in denen PL / PgSQL zu eingeschränkt ist. PL / Pythonu macht den Job, wenn Sie Python bevorzugen, aber kein Sicherheitsmodell wie PL / Perl anbieten. Es gibt auch PL / V8 (JavaScript) als Add-On.
Craig Ringer

1
Hallo cataldo, ich möchte dich nur auf der Seite begrüßen, da dies deine erste Frage hier ist. Danke fürs posten und ich hoffe du bleibst dabei.
Jack Douglas

Antworten:


27

PL / PgSQL- und einfache SQL-Funktionen sind beide Teil eines größeren Werkzeugsatzes und sollten in diesem Zusammenhang betrachtet werden. Ich neige dazu, es in einem aufsteigenden Leistungsmaßstab zu sehen, der mit steigender Komplexität und steigenden Kosten einhergeht, wobei Sie das einfachste Werkzeug verwenden sollten, das die Aufgabe gut erledigt:

  • Verwenden Sie nach Möglichkeit Ansichten
  • Wenn eine Ansicht nicht geeignet ist, verwenden Sie eine SQL-Funktion
  • Wenn eine SQL-Funktion nicht geeignet ist, verwenden Sie PL / PgSQL.
  • Wenn PL / PgSQL zu eingeschränkt oder nicht aussagekräftig genug ist, verwenden Sie PL / Perl, PL / Python, PL / V8, PL / Java oder was auch immer Sie bevorzugen
  • ... und wo kein PL die Arbeit machen wird, benutze ein externes Programm und eventuell LISTENund NOTIFYum mit ihm zu reden.

Sehr häufig ist eine Ansicht ausreichend, wenn Sie denken, dass eine Funktion benötigt wird. Auch wenn dies für SELECTdie gesamte Ansicht extrem teuer ist , werden WHEREKlauseln in der Abfrage, die auf die Ansicht verweisen, normalerweise in die Ansicht verschoben und können zu sehr unterschiedlichen Abfrageplänen führen. Ich habe oft große Leistungsverbesserungen durch das Konvertieren von SQL-Funktionen in Ansichten erhalten.

Wenn Sie feststellen, dass Sie eine Ansicht nicht verwenden können und eine SQL-Funktion in Betracht ziehen sollten, gilt Folgendes:

  • Parameter, die nicht als einfache WHEREKlauseln ausgedrückt werden können, werden wie ein Parameter in einem WITHAusdruck benötigt
  • Sie möchten eine Sicherheitsbarriere über eine SECURITY DEFINERFunktion, und die security_barrierAnsichten in PostgreSQL 9.2 und höher sind für Ihre Anforderungen nicht ausreichend.
  • Sie benötigen Parameter, die vom Optimierer nicht in Unterklauseln einer Ansicht verschoben werden und die direkter gesteuert werden sollen. oder
  • Es gibt viele Parameter oder es gibt viele Wiederholungen der Parameter, daher ist es unpraktisch, die Abfrage als Ansicht zu schreiben.

Bei den meisten dieser Aufgaben funktioniert eine einfache SQL-Funktion einwandfrei und ist oft einfacher zu lesen als PL / PgSQL. Deklarierte STABLEoder IMMUTABLE(und nicht deklarierte STRICToder SECURITY DEFINER) SQL-Funktionen können auch in die aufrufende Anweisung eingefügt werden. Dies beseitigt den Funktionsaufruf-Overhead und kann manchmal auch zu enormen Leistungsvorteilen führen, wenn eine WHERE-Bedingung in der aufrufenden Funktion vom Optimierer in die SQL-Funktion gedrückt wird. Verwenden Sie SQL-Funktionen, wenn sie für die Aufgabe ausreichen.

Die Hauptzeit, in der SQL-Funktionen den Job nicht ausführen, ist, wenn Sie viel Logik benötigen. Wenn / then / else-Operationen, die Sie nicht als CASEAnweisungen ausdrücken können , vielfache Wiederverwendung von berechneten Ergebnissen, Aufbauen von Werten aus Chunks, Fehlerbehandlung usw., ist PL / PgSQL dann nützlich. Wählen Sie PL / PgSQL, wenn Sie SQL-Funktionen nicht verwenden können oder wenn diese nicht gut passen, wie zum Beispiel für:

  • Dynamisches SQL und dynamisches DDL über die EXECUTEAnweisung
  • Wenn Sie RAISEFehler / Warnungen für die Protokolle oder Client möchten
  • Wenn Sie eine Ausnahmebehandlung benötigen, können Sie Fehler mit EXCEPTIONBlöcken abfangen und behandeln, anstatt die gesamte Transaktion bei einem Fehler zu beenden
  • Komplexe bedingte Logik, die nicht CASE ... WHENsehr gut passt
  • Viele wiederverwendete berechnete Werte, in die Sie nicht passen, WITHund CTEs
  • Dynamische Datensätze erstellen
  • Sie müssen eine Aktion ausführen, nachdem Sie die Ergebnismenge erstellt haben

Bei allgemeinen Tabellenausdrücken (CTEs), insbesondere bei beschreibbaren CTEs WITH RECURSIVE, verwende ich PL / PgSQL viel seltener als früher, da SQL so viel aussagekräftiger und leistungsfähiger ist. Ich benutze jetzt viel mehr Views und einfache SQL-Funktionen. Denken Sie daran, dass einfache SQL-Funktionen mehrere Anweisungen enthalten können. Die letzte Anweisung ist das Ergebnis der Funktion.


Sehr gut gesagt! (eine zusätzliche, wenn auch virtuelle +1 für die Erwähnung von beschreibbaren CTEs)
Dezso

Diese Antwort erklärt auch, warum einige Funktionen optimiert werden müssen .
Eonil

8

plpgsqlist eine vollständige prozedurale Sprache mit Variablen, Schleifenkonstrukten usw. Eine SQLFunktion ist einfach eine Unterabfrage. Eine SQL-Funktion kann, wenn sie deklariert STABLEoder IMMUTABLEnicht deklariert ist STRICT, häufig in die aufrufende Abfrage eingefügt werden, als ob sie auf jeder Referenz ausgeschrieben wäre.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.