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:
Statt `rowid` oder `ctid` zu verwenden, sollten möglichst logische Identifikatoren eingesetzt werden. Empfohlene Alternativen:
Wenn eine bestehende Anwendung auf `rowid` angewiesen ist, gibt es folgende Workarounds:
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.