In PostgreSQL möchte ich einen Safe-Wrapping-Mechanismus erstellen, der ein leeres Ergebnis zurückgibt, wenn eine Ausnahme auftritt. Berücksichtigen Sie Folgendes:
%Vor%Ich könnte das sichere Wrapping in der Client-Anwendung machen:
%Vor% Aber könnte ich so etwas direkt in SQL machen? Ich möchte den folgenden Code arbeiten lassen, aber es scheint so, als sollte er in DO $$ ... $$ block gesetzt werden und hier verlaufe ich.
Im Allgemeinen wird plpgsql-Code immer in einen BEGIN .. END -Block eingeschlossen. Das kann im Körper einer DO -Anweisung oder einer Funktion sein. Blöcke können innerhalb verschachtelt sein - aber sie können nicht außerhalb existieren, verwechseln Sie das nicht mit einfachem SQL.
Jeder BEGIN -Block kann optional eine EXCEPTION -Klausel für die Behandlung von Exceptions enthalten, aber Funktionen, die Exceptions abfangen müssen, sind erheblich teurer. Daher ist es am besten, Ausnahmen von vornherein zu vermeiden.
Weitere Informationen:
Das Handbuch zum Einfangen von Fehlern ( Ausnahmen behandeln) in PL / pgSQL
Beispiel: Ist SELECT oder INSERT in einer Funktion, die anfällig für Rennbedingungen ist?
Eine DO -Anweisung kann nichts zurückgeben. Erstellen Sie eine Funktion , die den Namen der Tabelle und des Schemas als Parameter akzeptiert und gibt zurück, was immer du willst:
Anruf:
%Vor%Oder:
%Vor% Angenommen, Sie möchten eine Reihe von Zeilen mit einer einzelnen Spalte text oder eine leere Zeichenfolge, wenn die Tabelle nicht existiert.
Auch unter der Annahme, dass eine Spalte value existiert, wenn die angegebene Tabelle existiert. Du könntest das auch testen, aber du hast darum nicht gebeten.
Beide Parameter sind case sensitive text -Werte. Das unterscheidet sich subtil von der Art und Weise, wie Bezeichner in SQL-Anweisungen behandelt werden . Wenn Sie keine Bezeichner doppelt zitieren, übergeben Sie Kleinbuchstaben und Sie sind in Ordnung.
Der Schemaname lautet in meinem Beispiel standardmäßig 'public' . Passen Sie sich Ihren Bedürfnissen an. Sie könnten das Schema sogar komplett ignorieren und standardmäßig die aktuelle search_path .
to_regclass() ist neu in Postgres 9.4 . Bei älteren Versionen ersetzen Sie:
Das ist eigentlich genauer , weil es genau das testet, was Sie brauchen. Weitere Optionen und detaillierte Erklärung:
Verteidigen Sie immer gegen SQL-Injektion, wenn Sie mit dynamischem SQL arbeiten! Der Cast auf regclass macht hier den Trick. Weitere Details:
Tags und Links sql exception-handling postgresql plpgsql dynamic-sql