CREATE SEQUENZE fehler

Hallo,

ich habe ein kleines PL/PgSQL Skript geschrieben, hier ein Ausschnitt davon:
(PostgreSQL 8.4.7)

.....
EXECUTE 'CREATE TABLE "' || tablename || '" ( LIKE "' || tablename_data || '" INCLUDING INDEXES )';

tablename_seq := tablename || '_id_seq';

EXECUTE 'CREATE SEQUENCE "' || tablename_seq || '"';
EXECUTE 'ALTER TABLE "' || tablename || '" ALTER COLUMN id SET DEFAULT NEXTVAL(' || quote_literal(tablename_seq) || ')';
....

Beim Ausführen kommt immer dieser Fehler:

SQL-Fehler:


ERROR: relation “data_optimized_dagobert1_filesystem_/local/nfss-local-links/sha” already exists
CONTEXT: SQL statement “CREATE SEQUENCE “data_optimized_dagobert1_filesystem_/local/nfss-local-links/share_id_seq””
PL/pgSQL function “optimize” line 33 at EXECUTE statement


Und das obwohl die Tabelle und Sequenz mit dem Namen noch gar nicht existieren.
Weiss eienr woran es liegen kann ?
Evtl an Länge der Sequenz ? Begrenzt auf 64 Zeichen ?

viele Grüsse,
Sergius

Mittlerweile habe ich rausgefunden, dass es nur die ersten 64 Zeichen gespeichert werden, auch wenn man mehr eingibt.

Also
CRETE SEQUENZE “abcd…64abc” // 67 Zeichen lang
das gleiche ist wie
CRETE SEQUENZE “abcd…64def” // 67 Zeichen lang

deswegen kommt diese Meldung mit already exists.

Gibt es denn in PostgresSQL eine Möglichkeit “längere” Sequenzen abzuspeichern ?

Du könntest theoretisch PostgreSQL neu compilieren und NAMEDATALEN ändern.
Aber: wieso reichen dir 64 Zeichen nicht?

Die Tabellen werden dynamisch erstellt anhang von bestimmten Kriterien,
die Namen werden also so generiert, dass die Tabellen wiedererkannt werden,
und es kommen teilweise bis zu 128 Zeichen.

Neukompilieren kommt leider nicht in die Frage.

Dann muss ich mir wohl was anderes überlegen.

Einfach: nur maximal 63 Zeichen generieren :wink:

Wenn die Welt so einfach wäre :slight_smile:

Die Sequenzen Namen setzen sich ungefähr so zusammen:
data_optimized_[rechnername][category][mountpoint]_id_seq

Beispiel:
data_optimized_dagobert1_filesystem_/local/nfss-local-links/share_id_seq

Man könnte jetzt natürlich anstatt von “data_optimized_” ein “do_” machen und am ende anstatt von “_id_seq” ein “_s”.
Aber die Mountpoints können viel Länger sein, und werden die Länge sprengen.
Die kann ich nicht kürzen, da wie gesagt alles dynamisch ist und die müssen uniq sein und wiedererkannt werden.

Die einzelne Lösung die ich gerade sehe, eine Extra Tabelle zu machen, die dann diese Namen speichert und die Sequenz Namen an sich dann ungefähr so zu machen:
…dagobert1_0001_seq - …dagobert1_9999_seq
Aber das ist dann auch ein Hack.

Das ist sowieso ungünstig. Was ist, wenn dein Verzeichnisname Sonderzeichen enthält?
Nimm irgendwelche Prüfsummen dafür, das grenzt das ganze sogar auf eine begrenzte Länge ein.

Ich muss ja im weiteren Verlauf wieder auf die Namen kommen und die Prüfsumme ist nicht zurückkonvertierbar.

Dann nimm auf jeden Fall irgendwelche IDs und halte die eigentlichen Namen in einer Tabelle vor.
Alles andere eröffnet dir zu viele Probleme - speziell mit ungefilterten Eingaben.

[quote=“ads”]Dann nimm auf jeden Fall irgendwelche IDs und halte die eigentlichen Namen in einer Tabelle vor.
Alles andere eröffnet dir zu viele Probleme - speziell mit ungefilterten Eingaben.[/QUOTE

“Die einzelne Lösung die ich gerade sehe, eine Extra Tabelle zu machen, die dann diese Namen speichert und die Sequenz Namen an sich dann ungefähr so zu machen:
…dagobert1_0001_seq - …dagobert1_9999_seq
Aber das ist dann auch ein Hack.”

Hatte ich ja vor :slight_smile:

Mir scheint, Du machst einen prinzipiellen Fehler: Du speichert zu speichernde Daten nicht in einer Tabelle, sondern im Schema der DB.


Andreas

Du siehst das falsch. Aber das kannst du gerade auch nicht wissen, weil ich nicht das gesammte Konzept hier aufschreiben kann.
Die eigentliche Daten werden schon natürlich in der Tabelle gespeichert.

Nun ja, ist Deine Sache. Aber eine Pfadangabe als Teil des Tabellennamens zu verwenden ist, hüstel, zumindest ungewöhnlich …


Andreas