• Ist die gewünschte Version verfügbar?

• Ist absehbar, dass zukünftige Versionen rechtzeitig verfügbar sein werden?

• Wie ist die Qualität der Paketierung?

• Bestehen Sonderwünsche, die die Paketierung nicht erfüllt?

• Womit ist der Administrator am besten vertraut?

• Compiler pools müssen bereitgestellt werden.

• Abhängigkeiten müssen selbst verwaltet werden.

• Benutzer und Dateisystemrechte müssen eingestellt werden.

• Startskripten müssen geschrieben und konfiguriert werden.

• Logging, Wartung, Datensicherung und Ähnliches müssen erledigt werden.

Bevor man die Einrichtung eines PostgreSQL-Systems angeht, sollte man sich klarmachen, welche Versionen es gibt und welche von ihnen man verwenden möchte.

PostgreSQL verwendet eine dreiteilige Versionsnummer , zum Beispiel 8.4.10 oder 9.2.0. Die erste Ziffer der Versionsnummer ändert sich nur sehr selten, nämlich dann, wenn eine neue »Ära« im Projekt anbricht. Die zweite Ziffer ändert sich, wenn ein neues großes Release mit neuen Features ausgeliefert wird. Die dritte Ziffer der Versionsnummer ändert sich mit jedem kleinen Release, das nur kritische Fehler berichtigt.

Dieses Versionsnummernschema ist aus technischer Sicht etwas unpassend, denn die erste und die zweite Zahl bilden im Prinzip eine Einheit. Aus Sicht der Entwickler gibt es einen großen Releasezweig »9.2« mit den Unterversionen 9.2.0, 9.2.1 und so weiter, je nachdem, wie oft Fehlerkorrekturen in dem Zweig notwendig werden. Insofern sind etwa 8.4 oder 9.2 als »Hauptversionsnummern« (major version) anzusehen, denn immer wenn sich die zweite Ziffer der Versionsnummer ändert (und eventuell auch die erste), enthält die neue Version neue Features. Wir verwenden den Begriff »Hauptversion« in diesem Buch in diesem Sinn. Die einzelne erste Ziffer (8 oder 9) hat eher repräsentativen Charakter, aber keine technischen Auswirkungen – die Unterschiede zwischen 8.4 und 9.0 sind vom Prinzip her nicht anders als die zwischen 8.3 und 8.4 oder die zwischen 9.0, 9.1 und 9.2. Es ist daher in jedem Fall falsch und sinnlos, etwa von einer Version »PostgreSQL 9« zu sprechen. (Das ist ähnlich wie beim Linux-Kernel. Auch da ist die Bezeichnung »Linux 2« oder »Linux 3« unsinnig.)

In der Praxis wird etwa einmal im Jahr eine neue Hauptversion herausgebracht. Es gibt dazu, wie bei Open Source-Projekten üblich, keinen lange voraus erdachten Releaseplan, aber dieser Zyklus hat sich über viele Jahre eingependelt. Man kann also, solange es in Zukunft keine gegenteiligen Bekanntmachungen gibt, davon ausgehen, dass es in etwa so weitergehen wird.

Eine Hauptversion bildet einen Zweig in der Entwicklung, der dann noch mehrere Jahre gewartet wird. Das heißt, es werden noch Fehlerkorrekturen eingespielt und etwa Übersetzungen verbessert und aktualisierte Zeitzonenregeln eingebaut, aber keine neuen Features mehr entwickelt. Dies wird auch fortgesetzt, nachdem die nächste Hauptversion veröffentlicht wurde. Es gibt also immer mehrere gepflegte Hauptversionen. Der Wartungszeitraum einer Hauptversion beträgt aktuell fünf Jahre ab Veröffentlichung der Version x.y.0. Einzelheiten dazu sowie eventuelle Abweichungen werden unter anderem über die Website des PostgreSQL-Projekts veröffentlicht. Es wird davon ausgegangen, dass man in diesem Zeitraum die Möglichkeit findet, den Umstieg auf eine neuere Hauptversion anzugehen. Die Spanne von fünf Jahren deckt sich auch ungefähr mit den Supportzeiträumen von Linux-Distributionen der »Enterprise«- oder »Long-Term-Support«-Klasse.

Wenn Anwender oder Entwickler neue Projekte angehen, die auf PostgreSQL aufsetzen, ist ihnen prinzipiell zu empfehlen, die neueste Hauptversion einzusetzen. Das gilt auch, wenn diese zum Beispiel bei Projektstart erst kurz vor der Veröffentlichung stehen. Eine neue Version hat immer mehr Features und eine bessere Leistung, und mittelfristig wird man sowieso nicht um sie oder eine spätere Version herumkommen, wenn man PostgreSQL weiterhin einsetzen möchte.

Unterversionen (minor releases) werden etwa alle paar Monate herausgebracht, je nachdem, wie oft Korrekturen notwendig sind. Meist werden dabei Unterversionen von allen noch gewarteten Hauptversionen gleichzeitig herausgebracht, wenn die Fehlerkorrekturen auf alle zutreffen. Unterversionen sollten in der Regel umgehend von allen Anwendern eingespielt werden. Wer eine paketbasierte Installation hat, wird in der Regel entsprechende Updates automatisch erhalten.

Für einige populäre Linux-Betriebssysteme stellen wir hier kurz die Installation von PostgreSQL aus Binärpaketen vor.