lx-office.sql: maxvalue in sequence id und glid zu groß für integer

[t.lange@…]

Gleich am Anfang in /sql/lx-office.sql wird in 'CREATE SEQUENCE...' maxvalue für
'id' und 'glid' auf 9223372036854775807 gesetzt. Das enspricht der maximalen
(positiven) Zahl im Datentyp int8. In sämtlichen Tabellen in denen mittels 'id'
und 'glid' hochgezählt wird (nächste id = id+1), findet man aber nur den
Datentyp integer = int4. Dessen maximaler Wert liegt aber bereits bei 2147483647.

Bei extrem großen Datenmengen oder häufigen Änderungen der id's bei ganz
speziellen LX-ERP-Anpassungen könnte das zu einem Datenbank-Fehler führen.
Entweder sollte der maxvalue heruntergesetzt werden auf 2147483647 oder die id's
in allen betroffenen Tabellen sollten auf bigint = int8 gesetzt werden.

Zu den Datentypen, siehe auch:
​http://www.postgresql.org/files/documentation/books/pghandbuch/html/datatype.html

Den 'maxvalue 9223372036854775807' findet man auch noch in weiteren *.sql.

(Mit Bezug zu comment 0)

Gleich am Anfang in /sql/lx-office.sql wird in 'CREATE SEQUENCE...' maxvalue für
'id' und 'glid' auf 9223372036854775807 gesetzt. Das enspricht der maximalen
(positiven) Zahl im Datentyp int8. In sämtlichen Tabellen in denen mittels 'id'
und 'glid' hochgezählt wird (nächste id = id+1), findet man aber nur den
Datentyp integer = int4. Dessen maximaler Wert liegt aber bereits bei 2147483647.

Bei extrem großen Datenmengen oder häufigen Änderungen der id's bei ganz
speziellen LX-ERP-Anpassungen könnte das zu einem Datenbank-Fehler führen.
Entweder sollte der maxvalue heruntergesetzt werden auf 2147483647 oder die id's
in allen betroffenen Tabellen sollten auf bigint = int8 gesetzt werden.

Danke für den Hinweis, das könnte mitunter kritisch werden. Zumindest bei der
"id". Ist zwar unwahrscheinlich, aber nicht ausgeschlossen.

Deswegen stufe ich den Bug hoch!

Zu den Datentypen, siehe auch:
​http://www.postgresql.org/files/documentation/books/pghandbuch/html/datatype.html

Den 'maxvalue 9223372036854775807' findet man auch noch in weiteren *.sql.

Danke, behoben durch Setzen des Maximalwertes aller Sequenzen auf 2147483647.

Anmerkung nebenbei: Wenn man bei PostgreSQL eine Tabelle mit einer Spalte vom
Typ "serial" anlegt, so mach PostgreSQL daraus ja eine Spalte vom Typ "integer
NOT NULL default nextval('tabelle_spalte_seq')" und legt eine neue Sequenz an,
die, wie unsere anderen Sequenzen, keinen Maximalwert besitzt (bzw.
9223372036854775807).