PL/pgSQL-Funktionen mit Tabellen-Rückgabe — RETURNS TABLE, SETOF und wann eine View besser ist

Eine View ist die eleganteste Art, eine wiederkehrende Abfrage zu kapseln — bis zu dem Moment, in dem die Abfrage ein Argument von außen braucht. Eine View kennt keine Parameter. Sobald im WHERE ein Wert stehen soll, den der Aufrufer mitgibt, ist die tabellenwertige Funktion das Mittel der Wahl: eine Funktion, die statt eines einzelnen Werts eine ganze Ergebnismenge … Weiterlesen

PL/pgSQL-Funktions-Konventionen — Volatilität, RETURNS und die Grenze zur Prozedur

Eine PL/pgSQL-Funktion ohne Volatilitäts-Marker ist per Default VOLATILE. Das klingt harmlos, kostet aber real: Der Planer ruft die Funktion pro Zeile erneut auf, berechnet sie nie einmalig vorab und schließt sie aus jedem funktionalen Index aus. Der Schaden ist unsichtbar — bis dieselbe Abfrage auf einmal Sekunden statt Millisekunden braucht. Gute PL/pgSQL-Funktions-Konventionen fangen genau hier an: nicht beim … Weiterlesen

SQL-Konventionen mit Claude Code ableiten — der Generate-Refine-Derive-Loop

Eine KI schreibt dir eine Stored Procedure in Sekunden. Sie kompiliert, sie läuft – und sie sieht aus, als hätte sie ein Fremder geschrieben. Beim nächsten Artefakt sieht sie wieder anders aus. Generierter SQL-Code ist technisch korrekt, aber stilistisch beliebig – und ohne durchgesetzte Konvention driftet eine generierte Sammlung genauso auseinander wie eine, an der fünf Entwickler … Weiterlesen

SQL-Konventionen // PL/pgSQL-Prozeduren, die man in zwei Jahren noch lesen kann

Wer eine Stored Procedure schreibt, schreibt sie für jemanden, der sie nicht kennt – meist für sich selbst, 18 Monate später, um 23 Uhr, während ein ETL-Lauf hängt. Lesbarkeit ist keine Kosmetik, sondern Debugging-Zeit. PostgreSQL zwingt einen zu fast nichts: Namen sind frei, Einrückung ist egal, ein RAISE EXCEPTION schluckt jeden inline-zusammengebauten Text. Genau deshalb driften Prozeduren-Sammlungen ohne Konvention innerhalb … Weiterlesen