Die Verwendung der `rowid` in SQL-Statements sollte mit Vorsicht erfolgen und nach Möglichkeit vermieden werden. Dies gilt insbesondere im Kontext von Datenbankmigrationen oder bei der Verwendung von Datenbank-Wrapping-Technologien wie z.B. dem Informix-Wrapper für PostgreSQL.

Laut IBM-Dokumentation wird empfohlen, sich nicht auf `rowid` zu verlassen, da sie systemabhängig ist und sich unter bestimmten Umständen ändern kann. (vgl. https://www.ibm.com/docs/de/informix-servers/12.10.0?topic=statements-rowid-values-in-select)

In Informix ist `rowid` ein Integer-Wert. In PostgreSQL gibt es kein direktes Äquivalent, aber es existiert die systeminterne Spalte `ctid`, die eine ähnliche Funktion übernimmt. (vgl. https://www.enterprisedb.com/postgres-tutorials/what-equivalent-rowid-postgresql?lang=en und https://www.postgresql.org/docs/current/ddl-system-columns.html)

Der Informix-Wrapper leitet die `rowid` grundsätzlich an die PostgreSQL-`ctid` weiter. Dabei gibt es jedoch wichtige technische Unterschiede:

• `rowid` in Informix ist ein einfacher Integer.
• `ctid` in PostgreSQL ist ein Tupel bestehend aus (page_number, tuple_index).
• Der Informix-Wrapper setzt `rowid` auf den ersten Wert von `ctid`, also ergibt sich die übergebene Form: `ctid = (rowid, 0)`.

• `ctid` ändert sich bei jeder UPDATE-Operation.
• Wird durch VACUUM FULL neu zugewiesen.
• Kann nach VACUUM ANALYZE wiederverwendet werden.
• Ist systemintern und nicht als dauerhaft eindeutiger Schlüssel geeignet.

Statt `rowid` oder `ctid` zu verwenden, sollten möglichst logische Identifikatoren eingesetzt werden. Empfohlene Alternativen:

• Primärschlüssel nutzen (z.B. durch `SERIAL` oder `BIGSERIAL` erzeugt).
• Aufbau geeigneter Indexstrukturen zur Performanceoptimierung.
• Logische Referenzen statt physischer Adressen (z.B. Foreign Keys auf Primärschlüssel).
• Anpassung der Anwendung, um auf `rowid`/`ctid` zu verzichten.

Wenn eine bestehende Anwendung auf `rowid` angewiesen ist, gibt es folgende Workarounds:

• Anlage einer eigenen physischen Spalte `rowid` vom Typ `BIGSERIAL` in der PostgreSQL-Zielstruktur.
• Aufbau eines dedizierten Index zur effizienten Suche.
• Anpassung der SQL-Statements in der Anwendung, um die neue Struktur zu unterstützen.

Hinweis: Die Verwendung von `ctid` als langfristiger Zeilenidentifikator sollte vermieden werden, da er sich durch normale Datenbankoperationen wie `UPDATE`, `VACUUM`, etc. verändern kann und somit nicht stabil ist.

Die `rowid` bzw. `ctid` sind für temporäre oder systeminterne Zwecke nützlich, sollten jedoch nicht als zuverlässige Referenz in langlebigen Anwendungen oder Datenmodellen verwendet werden. Stattdessen ist auf Primärschlüssel-basierte Logik umzusteigen.