PL/pgSQL-Programmierung — Seminar für Datenbankentwickler

Kurz gefasst — In zwei Tagen schreibst du Funktionen, Prozeduren und Trigger in PL/pgSQL, die auch unter Last und im Fehlerfall tun, was sie sollen; ein optionaler dritter Tag geht auf Tempo, Nebenläufigkeit und Auslieferung. Für Entwickler und Administratoren, die Geschäftslogik in die Datenbank verlagern und dabei nicht in die typischen Fallen laufen: falsche Volatilitäts-Kategorie, teure Schleifen, offener search_path.

Lernpfad des Seminars Der Standard umfasst zwei Blöcke: Sprache und Funktionen, dann Ablaufsteuerung, Fehlerbehandlung und Trigger. Der optionale Praxistag ergänzt Tempo, Nebenläufigkeit und Auslieferung. Sprache Funktionen, Prozeduren Blöcke, Parameter, Rückgabe Volatilität, Rechte Ablauf Fehler und Trigger Schleifen, Cursor, EXCEPTION dynamisches SQL, Audit Praxis — optional Tempo und Betrieb Pläne, Sperren, Messen Test, Auslieferung
Der Aufbau folgt der Reihenfolge, in der die Fehler entstehen: erst schreiben, dann steuern, dann messen. Der Praxisblock kommt auf Wunsch dazu.

Für wen ist dieses Seminar

Datenbankentwickler, die Geschäftslogik aus der Anwendung in die Datenbank verlagern und dafür mehr brauchen als CREATE FUNCTION. Anwendungsentwickler, die vorhandene Funktionen und Trigger pflegen und verstehen wollen, warum ein Aufruf plötzlich langsam wird. Datenbankadministratoren, die fremden PL/pgSQL-Code beurteilen, absichern und ausliefern müssen. Und Umsteiger aus T-SQL oder PL/SQL, die die Konzepte kennen, aber die PostgreSQL-Eigenheiten suchen — Volatilität, Subtransaktionen im EXCEPTION-Block, search_path.

Das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Was du mitbringen solltest

Sicheres SQL: SELECT mit Joins und Aggregaten, INSERT/UPDATE/DELETE, ein Verständnis von Primär- und Fremdschlüsseln. Programmiererfahrung in irgendeiner Sprache hilft, ist aber nicht zwingend — die Sprachkonstrukte werden erklärt.

Nicht vorausgesetzt werden PL/pgSQL-Kenntnisse, Erfahrung mit Triggern oder Wissen über den PostgreSQL-Planer. Wer bei SQL selbst noch unsicher ist, beginnt besser mit SQL Grundlagen und danach SQL Fortgeschritten — dort stehen Fensterfunktionen und CTEs, die hier als bekannt vorausgesetzt werden.

Inhalte im Überblick

Wann ein Trigger feuert Ein schreibendes Statement durchläuft zuerst den BEFORE-STATEMENT-Trigger, dann je Zeile den BEFORE-ROW-Trigger, dann die eigentliche Änderung, dann den AFTER-ROW-Trigger je Zeile und zuletzt den AFTER-STATEMENT-Trigger. Der BEFORE-ROW-Trigger kann die Zeile über NEW verändern oder mit NULL verwerfen. Im AFTER-ROW-Trigger ist NEW nur noch lesbar; dort gehört der Audit-Eintrag hin. Der AFTER-STATEMENT-Trigger sieht zusätzlich die Übergangstabellen. UPDATE … BEFORE STATEMENT einmal je Befehl BEFORE ROW NEW änderbar, NULL verwirft die Zeile Zeile wird geschrieben AFTER ROW NEW nur lesbar — Ort des Audits AFTER STATEMENT einmal je Befehl, sieht die Übergangstabellen
Die Reihenfolge entscheidet, was ein Trigger noch ändern darf — und wo ein Audit-Eintrag hingehört.

Sprache, Funktionen und Prozeduren

  • Ausführung im Serverprozess: Unterschied zu reinen SQL-Funktionen und zu Anwendungscode
  • CREATE FUNCTION und CREATE PROCEDURE — was Prozeduren seit PostgreSQL 11 können und Funktionen nicht
  • Blockstruktur: DECLARE, BEGIN, END, verschachtelte Blöcke, benannte Labels
  • Variablen und Typen: %TYPE, %ROWTYPE, RECORD, Arrays, zusammengesetzte Typen
  • Parameter: IN, OUT, INOUT, VARIADIC, Vorgabewerte, Überladung und ihre Tücken
  • Rückgabewerte: RETURN, RETURN NEXT, RETURN QUERY, SETOF, RETURNS TABLE

Volatilität und Rechte

  • Die Kategorien VOLATILE, STABLE und IMMUTABLE — warum der Planer sie braucht
  • Was eine falsche Volatilitäts-Angabe an Laufzeit und Ergebnis anrichtet
  • SECURITY DEFINER gegen SECURITY INVOKER
  • Der search_path als Sicherheitsproblem — und wie er festgesetzt wird

Ablaufsteuerung

  • Verzweigungen: IF, CASE
  • Schleifen: LOOP, WHILE, FOR, FOREACH, EXIT, CONTINUE
  • Cursor: implizite FOR-Schleife, expliziter Cursor, FETCH und MOVE
  • REFCURSOR als Rückgabewert an die Anwendung

Dynamisches SQL

  • EXECUTE mit USING
  • Bezeichner und Werte korrekt einsetzen: format() mit %I und %L
  • Warum String-Verkettung keine tragfähige Absicherung ist

Fehlerbehandlung

  • EXCEPTION-Blöcke, SQLSTATE und SQLERRM
  • Gezieltes RAISE in allen Stufen (NOTICE, WARNING, EXCEPTION)
  • GET DIAGNOSTICS und GET STACKED DIAGNOSTICS für belastbare Fehlermeldungen
  • Die implizite Subtransaktion eines EXCEPTION-Blocks — und was sie in Schleifen kostet

Trigger

  • BEFORE, AFTER und INSTEAD OF; Zeilen- gegen Statement-Ebene
  • NEW und OLD, die TG_-Variablen
  • Übergangstabellen (REFERENCING … TABLE) statt Zeilentrigger bei Massenänderungen
  • Constraint-Trigger und DEFERRABLE: Prüfungen ans Transaktionsende verschieben
  • Event-Trigger auf DDL-Ebene
  • Praxisfall: ein Audit-Trigger, der Änderungen protokolliert, ohne die Schreiblast zu verdoppeln

Tempo und Nebenläufigkeit (im erweiterten Praxistag)

  • Plan-Caching: generischer gegen spezifischen Plan, plan_cache_mode
  • Warum eine Schleife mit Einzelanweisungen je nach Zeilenzahl um Größenordnungen langsamer ist
  • Schleifen auflösen: dieselbe Aufgabe mengenbasiert formulieren
  • Messen statt raten: EXPLAIN (ANALYZE, BUFFERS) und auto_explain
  • FOR UPDATE SKIP LOCKED als Warteschlangen-Muster, Advisory Locks, Deadlock-Vermeidung
  • Wiederkehrende Fehlerquellen: mutable Funktionen in Index-Ausdrücken, stille Typumwandlung

Testen und Ausliefern (im erweiterten Praxistag)

  • RAISE-Protokollierung im Betrieb
  • Testfälle mit pgTAP, Laufzeitprofile mit plprofiler — beides praktisch an der Übungsumgebung
  • Funktionen versionieren, CREATE OR REPLACE und seine Fallen
  • Änderungen als Migration ausrollen

Dauer: 2 Tage — optional 3 Tage mit dem erweiterten Praxistag


Hinweis: Schwerpunkte und Tiefe passen wir bei Inhouse-Seminaren an euren Bestand an. Die obige Gliederung ist der geplante Standard-Aufbau des offenen Seminars.

Schleife gegen mengenbasierte Verarbeitung Links: eine Schleife setzt pro Zeile eine eigene Anweisung ab, jede mit Planung, Ausführung und Rückgabe. Rechts: ein einziges Statement verarbeitet alle Zeilen in einem Durchgang — der Planer sieht dabei die ganze Menge und kann entsprechend planen. Der Unterschied wächst mit der Zeilenzahl. Schleife: eine Anweisung je Zeile FOR r IN SELECT … LOOP UPDATE … WHERE id = r.id ← Zeile 1 UPDATE … WHERE id = r.id ← Zeile 2 … ← Zeile n n Durchläufe, n Ausführungen Mengenbasiert: ein Statement UPDATE ziel z SET … FROM quelle q WHERE z.id = q.id; ein Durchlauf, alle Zeilen — der Planer sieht die ganze Menge
Der Unterschied ist kein Feinschliff: er wächst mit der Zeilenzahl. Im Seminar messen wir beide Varianten mit EXPLAIN ANALYZE gegeneinander.

Was du danach kannst

  • Eine Funktion mit der passenden Volatilitäts-Kategorie deklarieren und begründen, warum der Planer sie dadurch anders behandelt
  • Einen Audit-Trigger schreiben, der NEW und OLD auswertet und in eine Protokolltabelle schreibt — auf der richtigen Trigger-Ebene
  • Dynamisches SQL mit format() und %I/%L bauen, das Bezeichner und Werte korrekt trennt, und erklären, warum String-Verkettung das nicht tut
  • Einen EXCEPTION-Block setzen und benennen, welche Subtransaktion er kostet und ab wann das in einer Schleife teuer wird
  • Eine Cursor-Schleife in ein mengenbasiertes Statement umschreiben und den Unterschied mit EXPLAIN ANALYZE belegen
  • Eine SECURITY DEFINER-Funktion so absichern, dass ein manipulierter search_path sie nicht umlenkt

Formate und Ablauf

Format Ablauf Passend wenn
Remote / Online Zwei Tage im virtuellen Klassenraum, optional drei; Übungsumgebung wird bereitgestellt Die Teilnehmer sitzen an verschiedenen Standorten
Inhouse vor Ort Zwei Tage bei euch vor Ort, optional drei; bundesweit, auf Wunsch an eurer eigenen Datenbank und euren echten Fällen Das Team lernt am gemeinsamen Bestand

Gearbeitet wird in kleinen Gruppen, damit für eigene Fragen Raum bleibt; die genaue Teilnehmerzahl stimmen wir bei der Anfrage ab. Jeder Abschnitt hat einen Übungsteil — die Beispiele laufen auf einer aktuellen PostgreSQL-Version, ältere Stände berücksichtigen wir auf Wunsch.

Verwandte Seminare und Vertiefung

Wer aus der SQL-Server-Welt kommt, findet in T-SQL Programmierung dieselben Themen für den Microsoft-Stack — die beiden Seminare sind bewusst parallel geschnitten, und der Vergleich hilft beim Umstieg in beide Richtungen. Für den Betrieb der Instanz, auf der die Funktionen später laufen, ist PostgreSQL Administration der passende Nachbar: dort geht es um Konfiguration, Sicherung und Überwachung statt um Code.

Fachlich vertieft wird das Tempo-Kapitel durch unseren Artikel zur Index-Optimierung — die Frage, warum eine Funktion langsam ist, endet fast immer bei einem fehlenden oder ungenutzten Index. Wer wissen will, was im Hintergrund aufräumt, während seine Trigger schreiben, findet das in VACUUM, REINDEX und CLUSTER. Und für die Datums- und Zeitfallen, die in fast jeder Funktion auftauchen, gibt es den Beitrag zum SQL-Datumsformat. Alle weiteren PostgreSQL-Seminare stehen in der Kategorie PostgreSQL.

Häufige Fragen (FAQ)

Wie lange dauert das Seminar?

Zwei Tage im Standard: die Sprache, die Trigger und die Fehlerbehandlung. Wer zusätzlich messen, Sperren verstehen und die Auslieferung üben will, bucht den dritten Tag dazu — er ist der Praxistag. Was für euch passt, klären wir bei der Anfrage.

Brauche ich Programmiererfahrung?

Nein, aber sicheres SQL. Die Sprachkonstrukte von PL/pgSQL werden erklärt; Joins, Aggregate und Fremdschlüssel setzen wir voraus. Wer dort noch unsicher ist, beginnt mit den SQL-Seminaren.

Ist das Seminar für Umsteiger aus Oracle oder SQL Server geeignet?

Ja, das ist sogar ein häufiger Fall. Die Konzepte sind ähnlich, die Unterschiede aber teuer: Volatilität, das Verhalten von EXCEPTION-Blöcken und der search_path haben in PostgreSQL keine direkte Entsprechung. Genau diese Stellen bekommen im Seminar zusätzlichen Raum.

Arbeiten wir mit eigenen Datenbanken oder mit Beispielen?

Im offenen Seminar mit einer bereitgestellten Übungsumgebung. Bei einer Inhouse-Schulung gerne an eurer eigenen Datenbank und euren echten Funktionen — das ist der Regelfall und meist der lehrreichere Weg.

Welche PostgreSQL-Version wird verwendet?

Eine aktuelle Version. Wenn ihr produktiv auf einem älteren Stand arbeitet, richten wir die Beispiele danach aus — Prozeduren gibt es zum Beispiel erst ab Version 11, und das ändert einen Teil der Agenda.

Wie viele Teilnehmer sind möglich?

Wir arbeiten in kleinen Gruppen, damit individuelle Fragen Raum haben. Die genaue Teilnehmerzahl stimmen wir bei der Anfrage mit dir ab.

Lassen sich die Inhalte anpassen?

Ja. Wenn bei euch Trigger im Mittelpunkt stehen und Cursor keine Rolle spielen, verschieben wir die Gewichte. Bei Inhouse-Seminaren ist das der Normalfall.

Was kostet die Teilnahme?

Der Preis richtet sich nach Format, Umfang und Teilnehmerzahl — gerne auf Anfrage. Preise verstehen sich netto zzgl. gesetzlicher Umsatzsteuer; das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Seminar anfragen

Nach deiner Anfrage melden wir uns mit einem Terminvorschlag und klären offene Fragen zu Format, Version und Schwerpunkten. Wenn ihr eigene Funktionen mitbringen möchtet, sehen wir sie uns im Rahmen der Anfrage kurz an, damit die Beispiele im Seminar zu eurem Bestand passen — vertraulich und nur zu diesem Zweck.