Warum eine reine Übersetzung nicht genügt

Eine Package-Spezifikation ist häufig ein Vertrag mit der Anwendung. Der Body enthält die Implementierung, interne Hilfsfunktionen und möglicherweise Zustand, der über mehrere Aufrufe erhalten bleibt. Wer nur einzelne Funktionen übersetzt, kann diesen Vertrag unbeabsichtigt ändern.

Im PostgreSQL-Kern gibt es kein Oracle-Package mit derselben Semantik. Schemas können Funktionen und Prozeduren ordnen; damit entstehen aber weder automatisch private Package-Mitglieder noch Package-Variablen. Beide Aspekte brauchen eine bewusste Zielentscheidung.

Schnittstellen und Zustand inventarisieren

  • Öffentliche Routinen, Parameter, Datentypen und Exceptions erfassen. Welche Aufrufe nutzt die Anwendung tatsächlich?
  • Package-Variablen und Initialisierungslogik markieren. Werden Werte pro Sitzung, Transaktion oder fachlichem Vorgang gehalten?
  • Interne Hilfsroutinen, Grants und Aufrufe über Schema-Grenzen aufnehmen.
  • Dynamisches SQL, Transaktionssteuerung und externe Nebenwirkungen gesondert prüfen.

Für die Priorisierung genügt nicht die Zeilenzahl. Ein kleines Package mit Sitzungszustand und vielen Aufrufern kann riskanter sein als ein großes Paket unabhängiger Berechnungen.

Beispiel: eine zustandslose Berechnung

Das folgende didaktische Beispiel isoliert eine einfache Berechnung. Es ist kein vollständiges Package-Migrationsmuster. In einer Testdatenbank mit Berechtigung zur Schema-Erstellung lässt sich die Zielroutine unabhängig von Anwendung und Produktivdaten prüfen.

PostgreSQL · isoliertes Funktionsbeispiel
CREATE SCHEMA IF NOT EXISTS migration_demo;

CREATE OR REPLACE FUNCTION migration_demo.bruttobetrag(
  p_netto numeric,
  p_steuersatz numeric
) RETURNS numeric
LANGUAGE sql
IMMUTABLE
RETURNS NULL ON NULL INPUT
AS $$
  SELECT round(p_netto * (1 + p_steuersatz), 2);
$$;

SELECT migration_demo.bruttobetrag(100, 0.19);
-- Erwarteter Wert: 119.00

SELECT migration_demo.bruttobetrag(NULL, 0.19);
-- Erwarteter Wert: NULL

Hier sind NULL-Verhalten und Rundung ausdrücklich festgelegt. Bei einer echten Portierung müssen diese Entscheidungen zum bisherigen fachlichen Verhalten passen. Ein Parameter mit Standardwert oder eine andere Rundungsregel wäre bereits eine Änderung der Schnittstelle.

Package-Zustand bewusst neu modellieren

Ein durchgereichter Kontextparameter kann Abhängigkeiten explizit machen. Eine Sitzungstabelle kann für bestimmte Anforderungen geeignet sein, bindet das Verhalten jedoch an die Verbindung. Dauerhafter fachlicher Zustand gehört gegebenenfalls in ein reguläres Datenmodell oder in die Anwendung.

Connection Pooling mitdenken

Wenn Anwendungsaufrufe unterschiedliche Datenbankverbindungen verwenden, ist Sitzungskontext keine verlässliche fachliche Übergabe. Testen Sie das Zielmodell mit dem tatsächlichen Pooling-Verhalten und mit parallel laufenden Aufrufen.

Auch die Sichtbarkeit interner Routinen ist eine Berechtigungsentscheidung. Nutzen Sie separate Rollen und überprüfen Sie die tatsächlichen Ausführungsrechte. Ein anderer Name oder ein separates Schema allein macht eine Funktion nicht privat.

Ein überprüfbares Arbeitspaket bilden

  • Einen fachlichen Vorgang auswählen und alle zugehörigen Aufrufer bestimmen.
  • Altes und neues Verhalten mit gleichen Eingaben vergleichen: Normalfälle, NULL, Grenzwerte, Fehlermeldungen und Transaktionen.
  • Mehrfachaufrufe, Verbindungswechsel und parallele Verarbeitung testen.
  • Berechtigungen mit der echten Anwendungsrolle prüfen.
  • Erst nach dem Pilot Annahmen und Aufwand für ähnliche Packages übertragen.

Das Ergebnis sollte eine Zuordnung von Oracle-Routine zu Zielroutine, Testfall und Verantwortlichem sein. So wird aus einer groben Konvertierungsliste ein umsetzbares Migrationspaket.

Originalquellen & Vertiefung

Die Empfehlungen sind eine fachliche Einordnung. Konkrete Optionen hängen von Quell- und Zielversion, Rechten und Betriebsmodell ab.