Funktionsmatrix

Wie vollständig eine Migration ausfällt, hängt stark von der Quelldatenbank ab. Die folgende Tabelle zeigt den Status je Connector und Funktion. Sie entspricht der Datei FEATURE_MATRIX.md im Repository, die die maßgebliche Fassung ist und mit den Quelltexten der Connectoren abgeglichen wird — jeder Eintrag entspricht tatsächlich vorhandenem Code, nicht einer Planung.

Legende

#

Das Schwierigste daran, ein ? zu einem yes zu machen, ist meist, eine Testdatenbank zu finden, die die betreffende Funktion in realistischer Weise einsetzt.

Unterstützung je Connector

#

Abkürzungen der Spalten: DB2 LUW / z/OS / i = IBM-DB2-Varianten, MSSQL = MS SQL Server, SQL Any. = SQL Anywhere, Sybase = Sybase ASE.

Anmerkungen

#

1. IDENTITY-Spalten (Oracle). Werden anhand der als Default-Wert verwendeten Sequenz erkannt. Die Datentypen bleiben ein Problem: Oracle erlaubt einen Primärschlüssel auf NUMBER mit einer Sequenz, während eine PostgreSQL-Identity-Spalte INT oder BIGINT sein muss.
2. Sequenzen. Bei den meisten Engines werden sie nicht als eigenständige Objekte migriert. SERIAL/BIGSERIAL, Identity-Spalten und Spalten mit einer Sequenz als Default werden zu PostgreSQL-Identity-Spalten; die Sequenz wird also automatisch angelegt und ihr aktueller Wert anschließend aus den migrierten Daten gesetzt. Oracle migriert zusätzlich eigenständige Sequenzen als unabhängige PostgreSQL-Sequenzen (siehe Anmerkung 7).
3. Check-Regeln / Domains. Extern definierte Prüfungen, die an eine Spalte oder einen Datentyp gebunden sind — Domains in PostgreSQL, Rules in einigen anderen Engines. Derzeit für Sybase ASE in Umsetzung.
4. Defaults in Sybase ASE. CREATE DEFAULT erzeugt einen benannten Default, der an mehrere Spalten gebunden werden kann. PostgreSQL kennt dazu kein Gegenstück, daher wird der zugrunde liegende Default-Wert direkt an jede Zielspalte gehängt.
5. Berechnete Spalten in Sybase ASE. Sybase legt für funktionsbasierte Indizes verborgene berechnete Spalten an (z. B. sybfi4_1 AS LOWER(ProductName) MATERIALIZED), was auch die in den Systemtabellen hinterlegte Index-DDL verändert.
6. Implizite Default-Ersetzungen. Gängige Default-Werte, deren Syntax PostgreSQL nicht akzeptiert, werden während der Migration implizit ersetzt.
7. Oracle. Check-Constraints, eigenständige Sequenzen, benutzerdefinierte Datentypen, Domains, Tabellen- und Spaltenkommentare, Views und materialisierte Views sowie eine PL/SQL-Konvertierung nach bestem Bemühen sind implementiert, jedoch noch nicht gegen eine laufende Datenbank verifiziert. Die PL/SQL-Konvertierung arbeitet heuristisch: Packages werden in eigenständige Funktionen <package>_<routine> aufgeteilt und die Aufrufstellen umgeschrieben (der Package-Zustand wird nicht migriert), Trigger werden zu einer PL/pgSQL-Triggerfunktion plus CREATE TRIGGER, und komplexe Konstrukte werden zur manuellen Nachbearbeitung markiert. Objekttypen werden zu zusammengesetzten Typen; Collection-Typen (VARRAY, verschachtelte Tabellen) werden zu Array-basierten Domains.
8. SQLite. SQLite besitzt für mehrere dieser Objekte kein Data Dictionary, daher werden Check-Constraints, Ausdrücke generierter Spalten, AUTOINCREMENT-Markierungen und Ausdrücke funktionaler Indizes aus den CREATE-Anweisungen in sqlite_master herausgelesen. Views, Trigger und Ausdrücke werden mit sqlglot und einem SQLite-spezifischen Funktions-Mapping übersetzt. Partielle Indizes verlieren ihre WHERE-Bedingung (sie wird im Indexkommentar festgehalten), und ein partieller Unique-Index wird zu einem nicht eindeutigen Index herabgestuft. Virtuelle Tabellen (FTS, RTREE, …) und ihre Shadow-Tabellen werden übersprungen. Da SQLite dynamisch typisiert ist, werden die Werte während der Datenmigration in den Typ der Zielspalte überführt.
9. IBM DB2 z/OS und DB2 for i. Dies sind offline-Connectoren — sie verbinden sich nie mit der Quellinstanz. Die Struktur wird aus .sql/DDL-Extrakten (connectivity: "ddl") gelesen, die Daten aus quellseitig erzeugten CSV-Dateien. Alles, was eine laufende Quelle voraussetzt (Analyse vor der Migration, Validierung per Zufallsstichprobe und LOB-Größen), steht daher nicht zur Verfügung. COMMENT ON- und LABEL ON-Anweisungen werden aus der DDL gelesen und in den Protokolltabellen abgelegt, aber noch nicht auf das Ziel angewendet.
10. MySQL und MariaDB. Getrennte, weitgehend identische Connectoren. MariaDB migriert zusätzlich eigenständige SEQUENCE-Objekte (MariaDB 10.3+). Funktionen, Prozeduren und Trigger konvertiert keiner von beiden.
11. Mapping von SQL-Funktionen. Jeder Connector bringt ein Mapping gängiger SQL-Funktionen der Quelle auf PostgreSQL-Entsprechungen mit, das bei der Konvertierung von Defaults, Views, Constraints und Routinenrümpfen angewendet wird. Der Abdeckungsgrad unterscheidet sich je Engine und wird bei Bedarf erweitert — daher überall WIP. Für eine PostgreSQL-Quelle ist kein Mapping erforderlich.
12. Benutzerdefinierte Collations. Eigenständige CREATE COLLATION-Objekte, die von Spalten und Indizes referenziert werden; migriert für eine PostgreSQL-Quelle (ICU- und libc-Provider, Locale, Tailoring-Regeln, nicht-deterministische Collations, Kommentar). Collations anderer Engines (utf8mb4_general_ci, Latin1_General_CI_AS, …) haben kein PostgreSQL-Gegenstück, daher wird die Referenz verworfen und die Spalte behält den Default der Zieldatenbank.
13. Objekte der Volltextsuche. Wörterbücher und Textsuchkonfigurationen, die von generierten tsvector-Spalten, Views, Indizes und Funktionen referenziert werden. Migriert für eine PostgreSQL-Quelle einschließlich des vollständigen Mappings der Token-Typen; Referenzen innerhalb von 'name'::regconfig-Literalen werden umgeschrieben. Objekte, die zu einer Extension gehören, werden nicht migriert — sie kommen mit der Extension.
14. Benutzerdefinierte Aggregate. CREATE AGGREGATE-Objekte, migriert für eine PostgreSQL-Quelle samt ihrer Übergangs-, Abschluss-, Parallel- und Moving-Aggregate-Hilfsfunktionen, Startwerte, Sortieroperatoren und Parallelitätssicherheit. Sie werden nach den Funktionen und Prozeduren angelegt, die sie referenzieren. Aggregate aus einer Extension werden nicht migriert.

Getestete Datenbankversionen

#

Fehlt Ihnen eine Quelldatenbank oder eine Funktion, die Sie benötigen? Unterstützung dafür kann bei Bedarf ergänzt werden — siehe Mitmachen.