Freebsd Port - wie geänderte Datei pg_config_manual.h einbinden?

Hallo,

ich möchte PG 8.4 neu compilieren und benötige einen geänderten Wert in der Datei pg_config_manual.h (NAMEDATALEN). Diese Datei wird zweimal im System abgelegt (/usr/local/include und /usr/local/include/postgresql/server), in beiden Vorkommen habe ich den Wert geändert.
Wenn ich den Port mit “portupgrade -f postgresql-server” neu baue, packt FreeBSD die Source jedesmal neu aus und kompiliert mit Standardvorgaben. Wie bekomme ich es hin, dass meine pg_config_manual.h verwendet wird?


danke,
Hendrik

Ich denke, mit dieser Frage bist du in einem BSD Forum gut aufgehoben.

Ich sehe da zwei Optionen:

  1. Du verzichtest auf portupgrade oder portmaster und führst den Update manuell mit make && make deinstall reinstall durch.
  2. Du legest in /usr/port/distfiles/postgresql ein modifziertes 8.4 er Source-Archiv an, dass dein modifzierte .h Datei enthält. Konsequenz ist, dass du unter /usr/ports/databases/postgresql84- auch die Checksums anpassen musst.

Danke für den Tipp. Ich habe mich für Variante 2 entschieden - hat funktioniert. Muss nur halt bei jedem Update dran denken.

Mal als kurze Frage: wieso reichen 64 Zeichen als Bezeichnerlänge nicht aus?

Da bin ich auch nur durch Zufall drauf gestoßen - Drupal 6 mit CCK und Views. Ich habe eigene Felder angelegt, und von einigen Feldern wurden die Inhalte in einem View nicht angezeigt. In der normalen Node-Ansicht waren die Daten zu sehen. Ein Blick in Pg-Log zeigte folgendes:

NOTICE:  identifier "node_data_field_materialdeadline_field_testfield_mit_langem_namen_value" will be truncated to "node_data_field_materialdeadline_field_testfield_mit_langem_nam"

Mein Feld in diesem Beispiel hieß “testfield_mit_langem_namen”. Den Rest baut Drupal dazu.
Das Thema ist bei den Drupalern wohl bekannt, aber Postgres wird dort eher wie ein Stiefkind behandelt. CCK, Views Field Aliases too long for PostgreSQL | drupal.org

Nicht dass die Feldnamen unbedingt so lang sein müssen, aber ich finde, wenn das Frontend die Eingabe zulässt, muss das Backend das auch verarbeiten können.

Gruß Hendrik

Da sage ich jetzt nichts zu …

Sehr komische Software.

Ich geh’ mal davon aus, dass die hauptsächlich MySQL verwenden, aber dort darf ein Spaltenname auch nur 64 Zeichen lang sein (zumindest laut Handbuch)

Was machen die bei Drupal denn wenn jemand Oracle oder DB2 einsetzen möchte? Da sind es nur 30 Zeichen…

Das interessiert dann wohl keinen - nur MySQL ist wichtig.

genau lautet auch die Empfehlung. Mysql 4.x oder Mysql 5.x …
Immerhin wird PG ja unterstützt - da bin ich froh.

Versteh’ ich immer noch nicht. MySQL hat doch die gleiche Längenbeschränkung bei Spaltennamen wie Postgres (OK, ein Zeichen mehr)

wahrscheinlich gibt es da die gleichen Probleme - nur schweigt Mysql dazu wie sonst auch…
Das würde diese Diskussion hier erklären - CCK fields are not showing up in Views | drupal.org

Also bei wem sollte man sich hier über das Problem beschweren?

Das sieht wie autogenerierter Code in Drupal aus, ist das richtig? Dann sollte man dort beim generieren gleich auf mögliche Längenbeschränkungen achten.

the article which you have shared with us is really useful for me because it have a knowledge of ein Synonym für

which i need for this sharing i really thanks to you