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?
Du verzichtest auf portupgrade oder portmaster und führst den Update manuell mit make && make deinstall reinstall durch.
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.
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.
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.