Re: FOREIGN KEY

Hallo,

On Mon, 26 Jan 2009 00:20:53 +0100 Olaf Radicke wrote:

> Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
>
> Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer
> zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der DB und
> jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes mal
> sage ich "ja" und trotzdem werde ich wieder nach dem Passwort gefragt.

Das funktioniert hier ohne Probleme. Aber so oft nutze ich pgAdminIII
nicht.

Wenn pgAdminIII allerdings Daten oder Strukturen falsch anzeigt, sind
die Maintainer sicherlich an einem Bugreport samt passendem Test
interessiert.

> Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie die
> aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Update
> wächst die Gefahr, das die Tabellen die durch eine Neuinstallation angelegt
> werden, anders aussehen, als die, die den Update-Prozess durchlaufen haben.
> Durch das Refactoring wurde das Problem auch noch verschärft.

Nun, psql zeigt die Informationen doch richtig an, oder? Wo ist das
Problem?

Wenn sich allerdings Update und Neuinstallation unterscheiden, ist euer
Update Prozess gehörig faul. Wie genau schaut so ein Update bei euch
aus?

> Vielleicht muss ich für den Upgrade einfach Test schreiben um herraus zu
> bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datensätze
> schreiben, lesen und löschen. Oh, mich grausts... Nur allein das
> Refactoring-Upgrade hat schon 1500 Zeilen SQL.

*brr* Testdaten in einer Produktivumgebung? Was genau wird das zum
Schluss? Die Tabellenstruktur kann man auch ohne Testdaten
herausfinden. Da gibt es zum einen "information_schema" und zum anderen
die Systemkataloge. Beides kann man abfragen und die Struktur
herausfinden.

1500 Zeilen Update Code? Hört sich erst mal nicht wirklich viel an.

Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors