postgres/doc/FAQ_german

                  H<EFBFBD>ufig gestellte Fragen (FAQ) zu PostgreSQL
                                       
   Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us).
   
   Deutsche <EFBFBD>bersetzung von Ian Barwick (barwick@gmx.net).
   
   Letzte Aktualisierung der deutschen <EFBFBD>bersetzung: So., den 16.1.2005,
   22:30 MEZ
   
   Die aktuellste Version dieses Dokuments liegt auf der
   PostgreSQL-Website:
     * http://www.postgresql.org/files/documentation/faqs/FAQ.html
       (engl.)
     * http://www.postgresql.org/files/documentation/faqs/FAQ_german.html
       (dt.)
       
   <EFBFBD>bersetzungen dieses Dokuments in andere Sprachen sowie plattform-
   spezifische FAQs k<EFBFBD>nnen unter http://www.postgresql.org/docs/faq/
   eingesehen werden.
     _________________________________________________________________
   
                             Allgemeine Fragen
                                      
   1.1) Was ist PostgreSQL? Wie wird es ausgesprochen?
   1.2) Welchem Copyright unterliegt PostgreSQL?
   1.3) Auf welchen Unix-Plattformen l<EFBFBD>uft PostgreSQL?
   1.4) Welche Nicht-Unix-Versionen sind verf<EFBFBD>gbar?
   1.5) Woher bekomme ich PostgreSQL?
   1.6) Wo bekomme ich Support f<EFBFBD>r PostgreSQL?
   1.7) Was ist die neueste Version von PostgreSQL?
   1.8) Welche Dokumentation ist f<EFBFBD>r PostgreSQL verf<EFBFBD>gbar?
   1.9) Wie erfahre ich von bekannten Bugs oder fehlenden Features?
   1.10) Wie kann ich SQL lernen?
   1.11) Ist PostgreSQL Y2K (Jahr 2000) f<EFBFBD>hig?
   1.12) Wie kann ich im Entwicklerteam mitarbeiten?
   1.13) Wie sende ich einen Fehler-Bericht?
   1.14) Wie l<EFBFBD>uft PostgreSQL im Vergleich zu anderen Datenbanksystemen?
   1.15) Wie kann ich PostgreSQL finanziell unterst<EFBFBD>tzen?
   
                        Fragen zu Benutzerprogrammen
                                      
   2.1) Gibt es ODBC-Treiber f<EFBFBD>r PostgreSQL?
   2.2) Welche Werkzeuge gibt es, um Web-Seiten mit PostgreSQL zu
   verbinden?
   2.3) Hat PostgreSQL eine grafische Benutzerschnittstelle?
   2.4) Welche Programmiersprachen k<EFBFBD>nnen mit PostgreSQL kommunizieren?
   
                           Administrative Fragen
                                      
   3.1) Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql?
   3.2) Wenn ich den postmaster starte, erhalte ich die Nachricht "Bad
   System Call" bzw. "core dumped". Warum?
   3.3) Wenn ich versuche, den postmaster zu starten, bekomme ich
   "IpcMemoryCreate"-Fehlermeldungen. Warum?
   3.4) Wenn ich versuche, den postmaster zu starten, bekomme ich
   "IpcSemaphoreCreate"-Fehlermeldungen. Warum?
   3.5) Wie regle ich Zugriffe von anderen Rechnern?
   3.6) Wie optimiere ich die Datenbank f<EFBFBD>r bessere Leistung?
   3.7) Welche Debugging-Funktionen sind bei PostgreSQL verf<EFBFBD>gbar?
   3.8) Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine
   Verbindung aufzubauen versuche. Warum?
   3.9) Was befindet sich im Verzeichnis pgsql_tmp/?
   3.10) Warum mu<EFBFBD> ich bei jeder neuen Hauptversion von PostgreSQL die
   komplette Datenbank exportieren und anschlie<EFBFBD>end reimportieren?
   3.11) Welche Hardware eignet sich f<EFBFBD>r den Betrieb mit PostgreSQL?
   
                             Fragen zum Betrieb
                                      
   4.1) Worin besteht der Unterschied zwischen Binary Cursors und Normal
   Cursors?
   4.2) Wie w<EFBFBD>hle ich per SELECT-Anweisung nur die ersten paar Zeilen
   bzw. eine beliebige Zeile in einer Abfrage aus?
   4.3) Wie finde ich heraus, welche Tabellen, Indizes, Datenbanken oder
   Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql
   verwendeten Abfragen?
   4.4) Wie entferne ich eine Spalte aus einer Tabelle? Wie <EFBFBD>ndere ich
   den Datentyp einer Spalte?
   4.5) Was ist die Maximalgr<EFBFBD><EFBFBD>e f<EFBFBD>r eine Zeile, eine Tabelle, eine
   Datenbank?
   4.6) Wieviel Plattenplatz wird ben<EFBFBD>tigt, um die Daten aus einer
   typischen Textdatei abzuspeichern?
   4.7) Meine Abfragen sind langsam oder nutzen die Indizes nicht. Warum?
   4.8) Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer
   ("GEQO") meine Abfrage auswertet?
   4.9) Was ist ein R-Tree Index?
   4.10) Was ist der "Genetic Query Optimizer"?
   4.11) Wie verfahre ich bei der Suche mit regul<EFBFBD>ren Ausdr<EFBFBD>cken und bei
   einer Suche, bei der Gro<EFBFBD>- und Kleinschreibweisen ignoriert werden?
   Wie verwende ich bei solchen Suchabfragen einen Index?
   4.12) Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist?
   4.13) Was ist der Unterschied zwischen den verschiedenen CHAR-Typen?
   4.14.1) Wie erzeuge ich ein serielles Feld mit automatischer Erh<EFBFBD>hung
   des Wertes?
   4.14.2) Wie bekomme ich den Wert einer SERIAL-Sequenz?
   4.14.3) F<EFBFBD>hrt currval() zu einer Race-Condition mit anderen Nutzern?
   4.14.4) Warum werden die Sequenzwerte nach einem Transaktionsabbruch
   nicht zur<EFBFBD>ckgesetzt? Warum gibt es L<EFBFBD>cken in der Nummerierung meiner
   Sequenz-/SERIAL-Spalte?
   4.15) Was ist ein OID? Was ist ein TID?
   4.16) Welche Bedeutung haben die verschiedenen Ausdr<EFBFBD>cke, die in
   PostgreSQL benutzt werden (z.B. attribute, class,...)?
   4.17) Wieso bekomme ich den Fehler: "FATAL: Memory exhausted in
   AllocSetAlloc()"?
   4.18) Wie kann ich feststellen, welche PostgreSQL-Version bei mir
   l<EFBFBD>uft?
   4.19) Bei "large-object"-Operationen kommt die Fehlermeldung: "invalid
   large obj descriptor". Warum?
   4.20) Wie kann ich eine Spalte erstellen, deren Default-Wert immer die
   aktuelle Uhrzeit enthalten soll?
   4.21) Warum sind meine Unterabfragen (subqueries), die IN verwenden,
   so langsam?
   4.22) Wie f<EFBFBD>hre ich einen OUTER JOIN durch?
   4.23) Wie kann ich Abfragen <EFBFBD>ber mehrere Datenbanken hinweg ausf<EFBFBD>hren?
   4.24) Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion
   zur<EFBFBD>ckgeben lassen?
   4.25) Warum kann ich tempor<EFBFBD>re Tabellen in PL/PgSQL-Funktionen nicht
   zuverl<EFBFBD>ssig erstellen bzw. l<EFBFBD>schen?
   4.26) Welche M<EFBFBD>glichkeiten zur Verschl<EFBFBD>sselung gibt es?
   
                            PostgreSQL erweitern
                                      
   5.1) Ich habe eine benutzerdefinierte Funktion geschrieben. Wenn ich
   sie in psql aufrufe, kommt ein core dump. Warum?
   5.2) Wie kann ich praktische neue Typen und Funktionen zu PostgreSQL
   hinzuf<EFBFBD>gen?
   5.3) Wie schreibe ich eine Funktion in C, die einen Tupel
   zur<EFBFBD>ckliefert?
   5.4) Ich habe eine der Quellendateien ge<EFBFBD>ndert. Warum macht sich die
   <EFBFBD>nderung beim erneuten Kompilieren nicht bemerkbar?
     _________________________________________________________________
   
                             Allgemeine Fragen
                                      
    1.1) Was ist PostgreSQL? Wie wird es ausgesprochen?
    
   Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
   Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
   
   PostgreSQL ist eine Weiterentwicklung des POSTGRES-Datenbank-Systems,
   eines zukunftsweisenden DBMS-Forschungsprototyps. W<EFBFBD>hrend PostgreSQL
   das leistungsf<EFBFBD>hige Datenmodell und die reichhaltigen Datentypen von
   POSTGRES beibeh<EFBFBD>lt, ersetzt es dessen PostQuel-Abfragesprache durch
   eine erweiterte Teilmenge von SQL. PostgreSQL und dessen kompletter
   Quellcode sind frei und <EFBFBD>ffentlich verf<EFBFBD>gbar.
   
   Die PostgreSQL-Entwicklung wird von einem Entwickler-Team
   durchgef<EFBFBD>hrt, die alle Teilnehmer der
   PostgreSQL-Entwicklungs-Mailingliste sind. Der aktuelle Koordinator
   ist Marc G. Fournier (scrappy@postgresql.org) (Anmeldem<EFBFBD>glichkeit:
   siehe unten). Dieses Team ist f<EFBFBD>r die Gesamtentwicklung von PostgreSQL
   verantwortlich. Es handelt sich um ein Gemeinschaftsprojekt, das nicht
   von einer bestimmten Firma kontrolliert wird. Lesen Sie die
   Entwickler-FAQ: http://www.postgresql.org/docs/faqs/FAQ_DEV.html wenn
   Sie an einer Mitarbeit interessiert sind.
   
   Die Autoren von PostgreSQL 1.01 waren Andrew Yu und Jolly Chen. Viele
   andere haben zur Portierung, zum Testen, zur Fehlersuche und zur
   Verbesserung des Codes beigetragen. Der urspr<EFBFBD>ngliche Postgres-Code,
   von dem PostgreSQL abstammt, ist auf die Arbeit von vielen
   Studierenden und Diplomanden sowie Programmierern zur<EFBFBD>ckzuf<EFBFBD>hren, die
   unter der Leitung des Professors Michael Stonebraker an der
   Universit<EFBFBD>t von Kalifornien, Berkeley arbeiteten.
   
   Der urspr<EFBFBD>ngliche Name der Software in Berkeley war Postgres. Als die
   SQL-Funktionalit<EFBFBD>t 1995 hinzugef<EFBFBD>gt wurde, wurde sein Name zu
   Postgres95 erweitert. Der Name wurde Ende 1996 in PostgreSQL ge<EFBFBD>ndert.
   
    1.2).Welchem Copyright unterliegt PostgreSQL?
    
   PostgreSQL unterliegt folgendem COPYRIGHT (Originaltext):
   
   PostgreSQL Data Base Management System
   
   Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
   Portions Copyright (c) 1994-6 Regents of the University of California
   
   Permission to use, copy, modify, and distribute this software and its
   documentation for any purpose, without fee, and without a written
   agreement is hereby granted, provided that the above copyright notice
   and this paragraph and the following two paragraphs appear in all
   copies.
   
   IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
   FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
   INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
   ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
   ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   
   THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
   MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
   PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
   CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
   UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
   
   Bei der obigen Lizenz handelt es sich um die BSD-Lizenz, die klassiche
   Open-Source-Lizenz. Sie schr<EFBFBD>nkt die Verwendung des Quellcodes in
   keine Weise ein. Wir m<EFBFBD>gen diese Lizenz und haben nicht vor, sie zu
   <EFBFBD>ndern.
   
   Es gilt die Copyright-Klausel im Original!
   
    1.3) Auf welchen Unix-Plattformen l<EFBFBD>uft PostgreSQL?
    
   Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
   Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
   jeweiligen Versionsfreigabe getestet wurden, sind in den
   Installations- Anleitungen aufgelistet.
   
    1.4) Welche Nicht-Unix-Portierungen sind verf<EFBFBD>gbar?
    
   Ab Version 8.0 l<EFBFBD>uft PostgreSQL auf Microsoft NT-basierten
   Betriebssystemen wie Windows 2000, XP und Server 2003. Ein
   vorgefertigtes Installationspaket (derzeit noch im Beta-Stadium) kann
   von http://pgfoundry.org/projects/pginstaller heruntergeladen werden.
   Einen <EFBFBD>berblick <EFBFBD>ber den aktuellen Stand bietet die Win32-FAQ:
   http://pginstaller.projects.postgresql.org/FAQ_windows.html.
   
   Unter Windows 95/98/ME ist es nur m<EFBFBD>glich, den Datenbankserver mit
   Hilfe der Cygwin-Umgebung (Unix-Portierungsbibliotheken) zu betreiben.
   Weitere Informationen hierzu gibt es in der CYGWIN-FAQ:
   http://www.postgresql.org/docs/faqs/text/FAQ_CYGWIN.
   
   Eine Portierung f<EFBFBD>r Novell Netware 6 gibt es unter
   http://forge.novell.com.
   
   F<EFBFBD>r OS/2 (eComStation) gibt es eine Version hier:
   http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgre
   SQL&stype=all&sort=type&dir=%2F
   
    1.5) Woher bekomme ich PostgreSQL?
    
   Der zentrale FTP-Server f<EFBFBD>r PostgreSQL ist der ftp-Server
   ftp://ftp.postgresql.org/pub/. Weitere Mirror-Sites sind auf der
   PostgreSQL-Website aufgelistet.
   
    1.6) Wo bekomme ich Support f<EFBFBD>r PostgreSQL?
    
   Die zentrale (englischsprachige) Mailing-Liste ist:
   mailto:pgsql-general@postgresql.org .
   
   Die Liste ist Themen vorbehalten, die PostgreSQL betreffen. Die
   Anmeldung erfolgt mit einer Email an die Adresse
   pgsql-general-request@postgresql.org mit folgenden Zeilen im Text
   (nicht in der Betreffzeile):
    subscribe
    end

   Es gibt auch eine Digest-Liste (eine Liste, die Mails zusammengefasst
   sendet). Um sich an dieser Digest-Liste anzumelden, senden Sie eine
   Email an pgsql-general-digest-request@postgresql.org mit folgendem
   Text:
    subscribe
    end

   Es gibt noch die Bug-Mailingliste. Die Anmeldung f<EFBFBD>r diese Liste
   erfolgt durch eine Email an bugs-request@postgresql.org mit folgendem
   Text:
    subscribe
    end

   Die Entwickler-Mailingliste kann mit einer Email an
   pgsql-hackers-request@postgresql.org abonniert werden. Die Email mu<EFBFBD>
   ebenfalls folgenden Text enthalten:
    subscribe
    end

   Eine deutschsprachige Mailing-Liste gibt es ebenfalls:
   http://archives.postgresql.org/pgsql-de-allgemein/; die Liste kann
   hier abonniert werden.
   
   Weitere Mailinglisten und Informationen zu PostgreSQL befinden sich
   auf der PostgreSQL-Homepage:
   
     http://www.postgresql.org
     
   Es gibt au<EFBFBD>erdem einen IRC-Channel bei EFNet und bei Freenode, Channel
   #PostgreSQL. Unter UNIX/Linux k<EFBFBD>nnen Sie mit z.B. irc -c '#PostgreSQL'
   "$USER" irc.freenode.net. bzw. irc -c '#PostgreSQL' "$USER"
   irc.phoenix.net daran teilnehmen.
   
   Eine Liste von Unternehmen, die Support f<EFBFBD>r PostgreSQL auf
   kommerzieller Basis leisten, kann unter
   http://techdocs.postgresql.org/companies.php eingesehen werden.
   
    1.7) Was ist die neueste Version von PostgreSQL?
    
   Die neueste Version von PostgreSQL ist 8.0.0 .
   
   Die Freigabe einer neuen Version erfolgt im Schnitt alle 6 bis 8
   Monaten.
   
    1.8) Welche Dokumentation ist f<EFBFBD>r PostgreSQL verf<EFBFBD>gbar?
    
   Einige Handb<EFBFBD>cher, Man-Pages und einige kleine Testprogramme sind in
   der Distribution enthalten. Siehe das /doc-Verzeichnis. Ausserdem sind
   alle Handb<EFBFBD>cher online unter http://www.postgresql.org/docs/
   verf<EFBFBD>gbar.
   
   Zwei B<EFBFBD>cher zu PostgreSQL sind online verf<EFBFBD>gbar unter
   http://www.postgresql.org/docs/awbook.html und
   http://www.commandprompt.com/ppbook/ .
   
   Eine Liste lieferbarer PostgreSQL-B<EFBFBD>cher befindet sich unter
   http://techdocs.postgresql.org/techdocs/bookreviews.php Diverse
   technische Artikel befinden sich unter http://techdocs.postgresql.org/
   .
   
   psql hat einige n<EFBFBD>tzliche \d-Befehle, um Informationen <EFBFBD>ber Typen,
   Operatoren, Funktionen, Aggregate, usw. zu zeigen.
   
    1.9) Wie erfahre ich von bekannten Bugs oder fehlenden Features?
    
   PostgreSQL unterst<EFBFBD>tzt eine erweiterte Teilmenge von SQL-92. Siehe
   unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
   f<EFBFBD>r eine Auflistung der bekannten Bugs, fehlenden Features und
   zuk<EFBFBD>nftigen Pl<EFBFBD>ne.
   
    1.10) Wie kann ich SQL lernen?
    
   Das PostgreSQL Book auf http://www.postgresql.org/docs/awbook.html
   bietet eine Einf<EFBFBD>hrung in SQL. Ein weiteres PostgreSQL-Buch befindet
   sich unter http://www.commandprompt.com/ppbook . Es gibt zudem nette
   Tutorials unter http://www.intermedia.net/support/sql/sqltut.shtm ,
   http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
   und http://sqlcourse.com .
   
   Eine weitere Empfehlung ist "Teach Yourself SQL in 21 Days, Second
   Edition", es ist unter http://members.tripod.com/er4ebus/sql/index.htm
   erh<EFBFBD>ltlich.
   
   Viele PostgreSQL-Anwender m<EFBFBD>gen "The Practical SQL Handbook" (Bowman
   et al., Addison Wesley). Andere dagegen m<EFBFBD>gen "The Complete Reference
   SQL" (Groff et al., McGraw-Hill).
   
    1.11) Ist PostgreSQL Y2K (Jahr 2000) f<EFBFBD>hig?
    
   Ja, wir k<EFBFBD>nnen Datumsangaben nach dem Jahr 2000 n.Chr. und vor 2000
   v.Chr. leicht verarbeiten.
   
    1.12) Wie kann ich im Entwicklerteam mitarbeiten?
    
   Zuerst laden Sie die neuesten Quellen herunter und lesen Sie die
   PostgreSQL-Entwicklerunterlagen auf unserer Website oder in der
   Distribution. Dann melden Sie sich zu den Entwickler-Mailinglisten
   pgsql-hackers und pgsql-patches an. Anschlie<EFBFBD>end senden Sie qualitativ
   hochwertige Patches an die pgsql-patches Mailingliste.
   
   Es gibt ungef<EFBFBD>hr ein Dutzend Leute, die das commit-Recht im PostgreSQL
   CVS-Archiv haben. Alle haben derart viele hochwertige Patches
   eingebracht, dass es f<EFBFBD>r die CVS-Verwalter schwer war, mitzuhalten.
   Und wir hatten Vertrauen, dass die von ihnen festgelegten <EFBFBD>nderungen
   aller Wahrscheinlichkeit nach von hoher Qualit<EFBFBD>t sind.
   
    1.13) Wie sende ich einen Fehlerbericht?
    
   Bitte besuchen Sie die PostgreSQL-BugTool-Seite
   http://www.postgresql.org/support/submitbug, die Hinweise und
   Anleitungen zur Einreichung von Fehlerberichten enth<EFBFBD>lt.
   
   <EFBFBD>berpr<EFBFBD>fe auch den ftp-Server ftp://ftp.postgresql.org/pub/, um
   nachzusehen, ob es eine neuere PostgreSQL-Version oder neue Patches
   gibt.
   
    1.14) Wie l<EFBFBD>uft PostgreSQL im Vergleich zu anderen Datenbanksystemen?
    
   Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
   Performanz, Zuverl<EFBFBD>ssigkeit, Support und Preis.
   
   Eigenschaften
          PostgreSQL besitt die meisten Eigenschaften - wie
          Transaktionen, Unterabfragen (Subqueries), Trigger, Views und
          verfeinertes Locking - die bei gro<EFBFBD>en kommerziellen DBMS
          vorhanden sind. Es bietet au<EFBFBD>erdem einige anderen
          Eigenschaften, die diese nicht immer haben, wie
          benutzerbestimmte Typen, Vererbung, Regeln, und die
          Multi-Versionen-Steuerung zum Verringern konkurrierender Locks.
          
   Performanz
          PostgreSQL weist eine Performanz auf, die mit der von
          kommerziellen und anderen Open-Source-Datenbanken vergleichbar
          ist. In manchen Bereichen ist es schneller, in anderen
          langsamer.
          
          Im Vergleich zu MySQL oder abgespeckten Datenbank-Systemen ist
          PostgreSQL in Lastsituationen - z.B. bei zeitgleichen Zugriffen
          durch mehrere Nutzer, bei komplexen Abfragen oder
          gleichzeitigen Lese- und Schreibzugriffen schneller. MySQL ist
          nur bei einfacheren SELECT-Abfragen mit wenigen Nutzern im
          Vorteil. MySQL besitzt allerdings nur wenige der im Punkt
          "Eigenschaften" genannten Features. PostgreSQL setzt auf
          Zuverl<EFBFBD>ssigkeit und Funktionsumfang, dabei wird selbstredend
          st<EFBFBD>ndig an Performanz-Verbesserungen gearbeitet.
          
   Zuverl<EFBFBD>ssigkeit
          Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
          zuverl<EFBFBD>ssig arbeitet. Daher bem<EFBFBD>hen wir uns, nur streng
          gepr<EFBFBD>ften und best<EFBFBD>ndigen Code freizugeben, der nur ein Minimum
          an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
          Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
          beweist, dass wir stabile und solide Versionen freigeben, die
          im Produktionsbetrieb genutzt werden k<EFBFBD>nnen. Wir glauben, dass
          wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
          dastehen.
          
   Support
          Unsere Mailinglisten bieten die M<EFBFBD>glichkeit, gemeinsam mit
          einer gro<EFBFBD>en Gruppe von Entwicklern und Benutzern m<EFBFBD>gliche
          Probleme zu l<EFBFBD>sen. Wir k<EFBFBD>nnen nicht immer eine Fehlerbehebung
          garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
          direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
          der Zugriff auf die Handb<EFBFBD>cher und den Quellcode erm<EFBFBD>glicht
          einen im Vergleich zu anderen DBMS h<EFBFBD>herwertigeren Support. Es
          gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
          (siehe FAQ-Punkt 1.6).
          
   Preis
          PostgreSQL ist frei verf<EFBFBD>gbar, sowohl f<EFBFBD>r die kommerzielle wie
          auch f<EFBFBD>r die nicht-kommerzielle Nutzung. Sie k<EFBFBD>nnen den
          PostgreSQL-Code ohne Einschr<EFBFBD>nkungen (au<EFBFBD>er denjenigen, die in
          der oben angegebene BSD-artigen Lizenz erw<EFBFBD>hnt werden) in Ihr
          Produkt integrieren.
          
    1.15) Wie kann ich PostgreSQL finanziell unterst<EFBFBD>tzen?
    
   PostgreSQL hat seit dem Anfang in 1996 eine exzellente Infrastruktur.
   Dies ist Marc Fournier zu verdanken, der sie <EFBFBD>ber die Jahre hinweg
   geschaffen und gepflegt hat.
   
   Eine hochwertige Infrastruktur ist f<EFBFBD>r ein Open-Source-Projekt wie
   dieses sehr wichtig. Sie verhindert Probleme und Verz<EFBFBD>gerungen beim
   Fortschritt des Projekts.
   
   Selbstverst<EFBFBD>ndlich ist diese Infrastruktur nicht billig. Es gibt eine
   Reihe von einmaligen und monatlich anfallenden Kosten, die f<EFBFBD>r den
   Betrieb beglichen werden m<EFBFBD>ssen. Falls Sie oder Ihre Firma dazu
   finanziell beitragen k<EFBFBD>nnen, besuchen Sie bitte die URL
   http://store.pgsql.com/shopping/ wo Sie eine Spende abgeben k<EFBFBD>nnen.
   
   Obwohl diese Web-Seite das Unternehmen "PostgreSQL, Inc." erw<EFBFBD>hnt, ist
   der Bereich "contributions" (Beitr<EFBFBD>ge) ausschliesslich f<EFBFBD>r die
   Unterst<EFBFBD>tzung des PostgreSQL-Projekts da und nicht f<EFBFBD>r die
   Finanzierung einer bestimmten Firma. Sie k<EFBFBD>nnen auch gerne einen
   finanziellen Beitrag an die Kontaktadresse verschicken.
   
   Eine M<EFBFBD>glichkeit der nicht-finanziellen Untetst<EFBFBD>tzung besteht <EFBFBD>brigens
   darin, f<EFBFBD>r http://advocacy.postgresql.org (en.) bzw.
   http://advocacy.postgresql.org/?lang=de (dt.) einen Bericht <EFBFBD>ber den
   erfolgreichen Einsatz von PostgreSQL in Ihrem Unternehmen oder in
   Ihrer Organisation bereitzustellen.
     _________________________________________________________________
   
                        Fragen zu Benutzerprogrammen
                                      
    2.1) Gibt es ODBC-Treiber f<EFBFBD>r PostgreSQL?
    
   Es sind zwei ODBC-Treiber verf<EFBFBD>gbar: PsqlODBC und OpenLink ODBC.
   
   PsqlODBC kann von
   http://gborg.postgresql.org/project/psqlodbc/projdisplay.php
   heruntergeladen werden.
   
   OpenLink ODBC kann unter http://www.openlinksw.com bezogen werden. Die
   Software arbeitet mit dem Standard-ODBC-Client dieser Firma, so dass
   PostgreSQL-ODBC auf jeder Client-Plattform zur Verf<EFBFBD>gung steht, die
   unterst<EFBFBD>tzt wird (Win, Mac, Unix, VMS).
   
   OpenLink wird dieses Produkt wahrscheinlich an Leute verkaufen, die
   kommerziellen Support ben<EFBFBD>tigen, dennoch wird immer eine
   Freeware-Version verf<EFBFBD>gbar sein. Fragen dazu bitte an
   postgres95@openlink.co.uk.
   
    2.2) Welche Werkzeuge gibt es, um Web-Seiten mit PostgreSQL zu verbinden?
    
   Eine nette Einf<EFBFBD>hrung zu datenbank-gest<EFBFBD>tzten Webseiten kann unter
   http://www.webreview.com (engl.) abgerufen werden.
   
   F<EFBFBD>r die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
   gibt es bei http://www.php.net
   
   F<EFBFBD>r komplexere Aufgaben bietet sich die Perl-Schnittstelle mit CGI.pm
   oder mod_perl.
   
    2.3) Hat PostgreSQL eine grafische Benutzerschnittstelle?
    
   Es gibt mehrere grafische Schnittstellen f<EFBFBD>r PostgreSQL, darunter
   PgAccess ( http://www.pgaccess.org), pgAdmin III
   (http://www.pgadmin.org, RHDB Admin (http://sources.redhat.com/rhdb/ )
   und Rekall ( http://www.thekompany.com/products/rekall/,
   GPL/propriet<EFBFBD>r). Es gibt au<EFBFBD>erdem phpPgAdmin (
   http://phppgadmin.sourceforge.net/ ), eine web-basierte Schnittstelle.
   
    2.4) Welche Programmiersprachen und Schnittstellen gibt es?
    
   Die meisten g<EFBFBD>ngigen Programmiersprachen bieten Schnittstellen f<EFBFBD>r
   PostgreSQL.
   
   Die folgenden Schnittstellen werden mit der PostgreSQL-Distribution
   ausgeliefert:
     * C (libpq)
     * Embedded C (ecpg)
     * Java (jdbc)
     * Python (PyGreSQL)
     * TCL (libpgtcl)
       
   Weitere Schnittstellen f<EFBFBD>r andere Sprachen k<EFBFBD>nnen <EFBFBD>ber
   http://gborg.postgresql.org (Bereich Drivers/Interfaces) bezogen
   werden.
     _________________________________________________________________
   
                           Administrative Fragen
                                      
    3.1) Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql?
    
   Bei der Ausf<EFBFBD>hrung von configure die Option --prefix mit dem
   Zielverzeichnis angeben.
   
    3.2) Wenn ich den postmaster starte, erhalte ich einen Nachricht "Bad
    System Call" bzw. "core dumped". Wieso?
    
   Das kann verschiedene Ursachen haben. <EFBFBD>berpr<EFBFBD>fen Sie zuerst, ob Ihr
   Kernel System V Extensions unterst<EFBFBD>tzt. PostgreSQL ben<EFBFBD>tigt
   Kernel-Unterst<EFBFBD>tzung f<EFBFBD>r Shared Memory und Semaphoren.
   
    3.3) Wenn ich versuche, den postmaster zu starten, bekomme ich
    "IpcMemoryCreate"-Fehlermeldungen. Warum?
    
   Entweder ist Shared Memory in Ihrem Kernel nicht korrekt konfiguriert,
   oder Sie m<EFBFBD>ssen den Shared Memory Bereich vergr<EFBFBD><EFBFBD>ern. Die genaue Gr<EFBFBD><EFBFBD>e
   h<EFBFBD>ngt von Ihrer Systemarchitektur und von der Anzahl der Puffer und
   Serverprozesse ab, die Sie f<EFBFBD>r postmaster konfiguriert haben. Bei den
   voreingestellten Werten f<EFBFBD>r Puffer und Prozesse ben<EFBFBD>tigen Sie bei den
   meisten Systemen ein Minimum von ca. 1 MB. Der "PostgreSQL
   Administrator's Guide"
   (http://www.postgresql.org/docs/current/static/kernel-resources.html)
   enth<EFBFBD>lt weitere Informationen zu Shared Memory und Semaphores.
   
    3.4) Wenn ich versuche, den postmaster zu starten, bekomme ich
    "IpcSemaphoreCreate"-Fehlermeldungen. Warum?
    
   Falls die Fehlermeldung "IpcSemaphoreCreate: semget failed (No space
   left on device)" lautet, ist Ihr Kernel mit zu wenig Semaphoren
   konfiguriert. PostgreSQL ben<EFBFBD>tigt eine Semaphore pro m<EFBFBD>glichem
   Backend-Prozess. Eine Zwischenl<EFBFBD>sung w<EFBFBD>re, postmaster mit einer
   geringeren Anzahl an Backend-Prozessen zu starten. Benutzen Sie dazu
   die -N Option mit einem kleineren Wert als die standardm<EFBFBD><EFBFBD>igen 32.
   Eine dauerhafte L<EFBFBD>sung w<EFBFBD>re es, die Parameter SEMMNS und SEMMNI Ihres
   Kernels zu erh<EFBFBD>hen.
   
   Nichtfunktionierende Semaphores k<EFBFBD>nnen au<EFBFBD>erdem bei hoher
   Datenbanklast zu Abst<EFBFBD>rzen f<EFBFBD>hren.
   
   Falls die Fehlermeldung anders aussieht, ist m<EFBFBD>glicherweise keine
   Semaphoren-Unterst<EFBFBD>tzung in Ihrem Kernel aktiviert. Der "PostgreSQL
   Administrator's Guide" enth<EFBFBD>lt weitere Informationen zu Shared Memory
   und Semaphores.
   
    3.5) Wie regle ich Zugriffe von anderen Rechnern?
    
   PostgreSQL ist standardm<EFBFBD><EFBFBD>ig so eingestellt, dass Verbindungen nur vom
   lokalen Rechner <EFBFBD>ber Unix Domain Sockets m<EFBFBD>glich sind. Verbindungen
   von anderen Rechnern <EFBFBD>ber TCP/IP sind nur m<EFBFBD>glich, wenn der postmaster
   mit der -i Option gestartet wird und / oder die Option
   listen_addresses (in 7.x-Versionen: tcpip_sockets) in postgresql.conf
   eingeschaltet wird, und die host-basierte Authentifizierung in der
   Datei $PGDATA/pg_hba.conf entsprechend angepasst ist.
   
    3.6) Wie optimiere ich die Datenbank f<EFBFBD>r bessere Leistung?
    
   Der Einsatz von Indizes sollte auf jeden Fall Abfragen beschleunigen.
   Die Anweisung EXPLAIN ANALYZE zeigt, wie PostgreSQL Abfragen
   interpretiert und welche Indizes benutzt werden.
   
   Wenn Sie eine gro<EFBFBD>e Anzahl von INSERT-Anweisungen durchf<EFBFBD>hren, sollten
   Sie <EFBFBD>berlegen, ob die Durchf<EFBFBD>hrung mit der COPY-Anweisung in Frage
   kommt. Dies funktioniert wesentlich schneller als einzelne
   INSERT-Befehle. SQL-Anweisungen, die sich nicht in einem BEGIN
   WORK/COMMIT Transaktions- Block befinden, werden als eigene
   Transaktionen behandelt. <EFBFBD>berlegen Sie, ob die Anweisungen nicht in
   einen einzelnen Transaktionsblock zusammen- gefasst werden k<EFBFBD>nnen. Das
   reduziert den Transaktionsaufwand. <EFBFBD>berlegen Sie auch, bei gr<EFBFBD><EFBFBD>eren
   Daten<EFBFBD>nderungen Indizes zu l<EFBFBD>schen und danach wiederherzustellen.
   
   Es gibt verschiedene Tuning-Optionen, die im Handbuch dokumentiert
   sind (Administration Guide/Server Run-time Environment/Run-time
   Configuration). Sie k<EFBFBD>nnen fsync() ausschalten, indem Sie beim Starten
   des postmaster die Optionen -o -F angeben. Das hindert
   fsync()-Operationen daran, nach jeder Transaktion die Daten direkt auf
   die Festplatte zu schreiben.
   
   Sie k<EFBFBD>nnen auch mit der shared_buffers Option des postmaster die
   Anzahl der Shared Memory Puffer f<EFBFBD>r die Backend-Prozesse erh<EFBFBD>hen.
   Falls Sie diesen Wert jedoch zu hoch setzen, kann es vorkommen, dass
   der postmaster nicht startet, weil die Obergrenze der
   Speicherzuweisung f<EFBFBD>r Shared Memory <EFBFBD>berschritten wird. Jeder Puffer
   ist 8 kB gro<EFBFBD>, voreingestellt sind 1000 Puffer.
   
   Die sort_mem (ab PostgreSQL 8.0: work_mem)-Optionen des Backends
   k<EFBFBD>nnen benutzt werden, um die Gr<EFBFBD><EFBFBD>e des Speicherplatzes f<EFBFBD>r tempor<EFBFBD>res
   Sortieren zu erh<EFBFBD>hen. Die Werte werden in Kilobyte gemessen und sind
   standardm<EFBFBD><EFBFBD>ig auf 1024 (d.h. 1MB) festgelegt.
   
   Die CLUSTER-Anweisung kann benutzt werden, um Daten in Basistabellen
   zu gruppieren, so dass - um einen schnelleren Zugriff zu erreichen -
   die physikalische Speicherung der Reihenfolge eines der Indexe
   entspricht. Siehe auch die CLUSTER(l) Man-Page f<EFBFBD>r weitere Details.
   
    3.7) Welche Debugging-Funktionen sind f<EFBFBD>r PostgreSQL verf<EFBFBD>gbar?
    
   PostgreSQL hat einige M<EFBFBD>glichkeiten, Statusinformationen anzuzeigen,
   die bei der Fehlersuche n<EFBFBD>tzlich sein k<EFBFBD>nnen.
   
   Wenn Sie PostgreSQL mit dem --enable-cassert Option kompiliert haben,
   verfolgen zahlreiche assert()-Anweisungen den Ablauf des Backends und
   halten das Programm an, wenn etwas Unerwartetes passiert.
   
   Sowohl der postmaster als auch postgres stellen mehrere Debug-Optionen
   zur Verf<EFBFBD>gung. Zuerst sollten Sie sichergehen, dass Sie die Ausgaben
   <EFBFBD>ber den Standard-Output und den Standard-Error in eine Datei
   umleiten, wenn Sie den postmaster starten:
      cd /usr/local/pgsql
      ./bin/postmaster >server.log 2>&1 &

   Dadurch wird die Datei server.log im PostgreSQL-Verzeichnis erzeugt.
   Diese Datei enth<EFBFBD>lt n<EFBFBD>tzliche Informationen <EFBFBD>ber Probleme oder Fehler,
   die im Server aufgetreten sind. postmaster hat eine -d Option, die
   noch detailliertere Informationen liefert. Zur -d Option wird eine
   Nummer angegeben, die den Debug-Level - also die Menge der berichteten
   Information - angibt. Achtung, hohe Debug-Levels erzeugen schnell
   gro<EFBFBD>e Logdateien!
   
   Wenn der postmaster nicht l<EFBFBD>uft, k<EFBFBD>nnen Sie das postgres-Backend sogar
   von der Befehlszeile ausf<EFBFBD>hren und eine SQL-Anweisung direkt eingeben.
   Dies ist allerdings nur f<EFBFBD>r Debugging-Zwecke zu empfehlen. Beachten
   Sie, dass hierbei ein Zeilenumbruch, und nicht - wie sonst <EFBFBD>blich -
   das Semikolon die SQL-Anweisung beendet. Falls Sie PostgreSQL mit
   Debugging-Symbolen kompiliert haben, k<EFBFBD>nnen Sie mit einem Debugger
   sehen, was passiert. Da das Backend jedoch nicht vom postmaster
   gestartet wurde, l<EFBFBD>uft es nicht in der gleichen Umgebung und deshalb
   k<EFBFBD>nnen einige locking-Vorg<EFBFBD>nge sowie die Kommunikation zwischen den
   Backends nicht reproduziert werden.
   
   Wenn der postmaster hingegen l<EFBFBD>uft, f<EFBFBD>hren Sie psql in einem Fenster
   aus, ermitteln Sie die Prozessnummer (PID) des postgres-Prozesses, der
   von psql verwendet wird (mit SELECT pg_backend_pid()). Binden Sie
   einen Debugger an diese PID und f<EFBFBD>hren Sie Abfragen von psql aus. Wenn
   Sie den postgres-Serverstart analysieren wollen, setzen Sie die
   Umgebungsvariable PGOPTIONS="-W n", und starten Sie dann psql. Dies
   verz<EFBFBD>gert den Start um n Sekunden, damit Sie einen Debugger an den
   Prozess binden und ggf. Breakpoints setzen k<EFBFBD>nnen, bevor die
   Startsequenz begonnen wird.
   
   Es gibt verschiedene Einstellungen (die log_*-Gruppe), die diverse
   Server-Statistik ausgeben und daher bei der Fehlersuche und
   Performanzmessung sehr n<EFBFBD>tzlich sein k<EFBFBD>nnen.
   
   Sie k<EFBFBD>nnen die Anwendung auch mit Profiling kompilieren, um zu sehen,
   welche Funktionen wieviel Ausf<EFBFBD>hrungszeit beanspruchen. Das Backend
   Profil wird im Verzeichnis pgsql/data/base/dbname abgelegt. Das
   Client-Profil wird in das aktuelle Verzeichnis abgelegt. Bitte
   beachtern Sie, dass unter Linux PostgreSQL mit der Option
   -DLINUX_PROFILE kompiliert werden mu<EFBFBD>, um Profiling nutzen zu k<EFBFBD>nnen.
   
    3.8) Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine
    Verbindung aufzubauen versuche. Warum?
    
   Sie m<EFBFBD>ssen die maximale Anzahl der gleichzeitig ausf<EFBFBD>hrbaren Backend-
   Prozesse hochsetzen.
   
   Die Voreinstellung erlaubt 32 Prozesse. Sie k<EFBFBD>nnen diese erh<EFBFBD>hen,
   indem Sie den postmaster mit einem entsprechenden -N Parameter starten
   bzw. die Konfigurationsdatei postgresql.conf anpassen.
   
   Bitte beachten Sie, dass Sie auch -B auf ein Wert gr<EFBFBD><EFBFBD>er als die
   Voreinstellung von 64 setzen m<EFBFBD>ssen, wenn Sie -N auf einen Wert h<EFBFBD>her
   als 32 setzen; -B muss mindestens das Doppelte von -N betragen, und
   einer besseren Performanz wegen sollte der Wert noch h<EFBFBD>her sein. Bei
   einer hohen Anzahl von Backend-Prozessen kann es vorkommen, dass Sie
   einige Unix-Kernel- Parameter ebenfalls erh<EFBFBD>hen m<EFBFBD>ssen. Folgende
   Parameter sind zu <EFBFBD>berpr<EFBFBD>fen: die Maximalgr<EFBFBD><EFBFBD>e der Shared Memory
   Blocks SHMMAX; die Maximalanzahl der Semaphoren SEMMNS und SEMMNI; die
   maximale Anzahl von Prozessen NPROC; die maximale Anzahl von Prozessen
   pro User MAXUPRC; und die Maximalzahl der ge<EFBFBD>ffneten Dateien NFILE und
   NINODE. Durch die Begrenzung der Anzahl erlaubter Backend-Prozesse
   wird verhindert, dass System-Ressourcen durch PostgreSQL aufgebraucht
   werden.
   
    3.9) Was befindet sich im Verzeichnis pgsql_tmp/?
    
   Dieses Verzeichnis enth<EFBFBD>lt tempor<EFBFBD>re Dateien, die durch den query
   executor erzeugt werden. Wenn zum Beispiel eine Sortierung
   durchgef<EFBFBD>hrt werden mu<EFBFBD>, um ein ORDER BY auszuf<EFBFBD>hren, und diese
   Sortierung mehr Hauptspeicher ben<EFBFBD>tigt, als mit dem Backend-Parameter
   -S erlaubt wurde, dann werden diese Dateien erzeugt, um die Daten dort
   zu auszulagern.
   
   Die tempor<EFBFBD>ren Dateien sollten automatisch gel<EFBFBD>scht werden. Falls das
   Backend jedoch w<EFBFBD>hrend einer Sortierung abst<EFBFBD>rzen sollte, bleiben sie
   erhalten. Nach einem Neustart des postmaster werden sie dann aber
   wieder automatisch gel<EFBFBD>scht.
   
    3.10) Warum mu<EFBFBD> ich bei jeder neuen Hauptversion von PostgreSQL die
    komplette Datenbank exportieren und anschlie<EFBFBD>end reimportieren?
    
   Zwischen "kleinen" PostgreSQL-Versions<EFBFBD>nderungen (z.B. zwischen 7.2
   und 7.2.1) werden keine strukturellen <EFBFBD>nderungen durchgef<EFBFBD>hrt, wodurch
   ein erneutes Aus- und Einlesen der Daten nicht erforderlich ist.
   Allerdings wird bei "gro<EFBFBD>en" Versions<EFBFBD>nderungen (z.B. zwischen 7.2 und
   7.3) oft das interne Format der Systemtabellen und Datendateien
   angepasst. Diese <EFBFBD>nderungen sind oft sehr komplex, wodurch die
   R<EFBFBD>ckw<EFBFBD>rtskompatibilit<EFBFBD>t der Datendateien nicht gew<EFBFBD>hrleistet werden
   kann. Durch das Exportieren werden die Daten in einem generischen
   Format ausgegeben, wodurch die Importierung in das neue interne Format
   erm<EFBFBD>glicht wird.
   
   Bei Upgrades, bei denen keine Format<EFBFBD>nderungen stattgefunden haben,
   kann das pg_upgrade-Skript benutzt werden, um die Daten ohne Aus- und
   Einlesen zu <EFBFBD>bertragen. Die jeweilige Dokumentation gibt an, ob f<EFBFBD>r
   die betreffende Version pg_upgrade verf<EFBFBD>gbar ist.
   
    3.11) Welche Hardware eignet sich f<EFBFBD>r den Betrieb mit PostgreSQL?
    
   PostgreSQL l<EFBFBD>uft auf fast jeder Hardware-Kombination. Im PC-Bereich
   gibt es allerdings sehr gro<EFBFBD>e Abweichungen in der Qualit<EFBFBD>t. F<EFBFBD>r einen
   Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
   sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
   Investition in teurere Bestandteile (Stichw<EFBFBD>rter ECC-Speicher, SCSI,
   Hauptplatinen und Netzteile von namhaften Herstellern).
     _________________________________________________________________
   
                             Fragen zum Betrieb
                                      
    4.1) Worin besteht der Unterschied zwischen Binary Cursors und Normal
    Cursors?
    
   Vgl. die DECLARE Man-Page f<EFBFBD>r eine Beschreibung.
   
    4.2) Wie w<EFBFBD>hle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw.
    eine beliebige Zeile in einer Abfrage aus?
    
   Vgl. die FETCH Man-Page, oder benutzen Sie SELECT ... LIMIT... .
   
   Selbst wenn Sie nur die ersten paar Zeilen einer Tabelle abfragen
   m<EFBFBD>chten, mu<EFBFBD> unter Umst<EFBFBD>nden die komplette Abfrage abgearbeitet
   werden. Ziehen Sie also m<EFBFBD>glichst eine Abfrage in Erw<EFBFBD>gung, die eine
   ORDER BY-Anweisung benutzt, welche wiederum auf indizierte Spalten
   verweist. In diesem Fall kann PostgreSQL direkt nach den gew<EFBFBD>nschten
   Zeilen suchen und braucht nicht jede m<EFBFBD>gliche Ergebniszeile
   abzuarbeiten.
   
   Bitte beachten Sie, dass mit PostgreSQL 7.3 die Syntax LIMIT n, m
   durch LIMIT n OFFSET m ersetzt wurde.
   
   Um eine beliebige Zeile auszuw<EFBFBD>hlen, nutzen Sie ORDER BY random():
       SELECT spalte
         FROM tabelle
     ORDER BY random()
        LIMIT 1


    4.3) Wie finde ich heraus, welche Tabellen, Indizes, Datenbanken oder
    Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql
    verwendeten Abfragen?
    
   In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
   psql-Befehle lassen sich mit \? anzeigen. Sie k<EFBFBD>nnen sich die Datei
   pgsql/src/bin/psql/describe.c mit dem Quellcode f<EFBFBD>r psql ansehen. Sie
   enth<EFBFBD>lt die SQL-Abfragen, die die Backslash-Kommandos (\) ausf<EFBFBD>hren.
   Sie k<EFBFBD>nnen psql auch mit der -E Option starten. Danach gibt psql die
   Abfragen aus, die es bei der Ausf<EFBFBD>hrung der Befehle benutzt. Au<EFBFBD>erdem
   biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
   Metainformation <EFBFBD>ber die Datenbank zur Verf<EFBFBD>gung stellt.
   
   Die Datei pgsql/src/tutorial/syscat.source enth<EFBFBD>lt au<EFBFBD>erdem viele
   SELECT- Abfragen, mit deren Hilfe man Information <EFBFBD>ber die
   Systemtabellen erhalten kann.
   
    4.4) Wie entferne ich eine Spalte aus einer Tabelle? Wie <EFBFBD>ndere ich den
    Datentyp einer Spalte?
    
   Der Syntax ALTER TABLE DROP COLUMN wird ab PostgreSQL 7.3 unterst<EFBFBD>tzt.
   
   Bei fr<EFBFBD>heren Versionen bietet das folgende Verfahren Ersatz:
      BEGIN;
      LOCK TABLE old_table;
      SELECT ...  -- alle au<EFBFBD>er der zu entfernenden Spalte hier ausw<EFBFBD>hlen
        INTO TABLE new_table
        FROM old_table;
      DROP TABLE old_table;
      ALTER TABLE new_table RENAME TO old_table;
      COMMIT;

   Um den Datentyp einer Spalte zu <EFBFBD>ndern, gehen Sie wie folgt vor:
       BEGIN;
       ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
       UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
       ALTER TABLE tabelle DROP COLUMN alte_spalte;
       COMMIT;


   Um den Speicherplatz freizugeben, der von der gel<EFBFBD>schten Spalte
   verwendet wurde, f<EFBFBD>hren Sie VACUUM FULL aus.
   
    4.5) Was ist die Maximalgr<EFBFBD><EFBFBD>e f<EFBFBD>r eine Zeile, eine Tabelle, eine Datenbank?
    
   Es bestehen folgende Obergrenzen:
    Maximale Gr<EFBFBD><EFBFBD>e eine Datenbank?           unbeschr<EFBFBD>nkt (es existieren
                                               Datenbanken mit 32 TB)
    Maximale Gr<EFBFBD><EFBFBD>e einer Tabelle?            32 TB
    Maximale Gr<EFBFBD><EFBFBD>e einer Zeile?              1,6 TB
    Maximale Gr<EFBFBD><EFBFBD>e einer Spalte?             1 GB
    Maximale Anzahl von Zeilen in einer Tabelle?
                                             unbeschr<EFBFBD>nkt
    Maximale Anzahl von Spalten in einer Tabelle?
                                             250-1600 je nach Spaltentyp
    Maximale Anzahl von Indizies f<EFBFBD>r eine Tabelle?
                                             unbeschr<EFBFBD>nkt

   Selbstverst<EFBFBD>ndlich sind dies theoretische Werte, die oft durch die
   verf<EFBFBD>gbaren Platten- und Speicherressourcen beschr<EFBFBD>nkt werden. Extreme
   Gr<EFBFBD><EFBFBD>en k<EFBFBD>nnen zu Leistungseinbu<EFBFBD>en f<EFBFBD>hren.
   
   Die maximale Tabellengr<EFBFBD><EFBFBD>e von 32 TB ben<EFBFBD>tigt keine
   Large-File-Unterst<EFBFBD>tzung im Betriebssystem. Gro<EFBFBD>e Tabellen werden in
   Dateien mit einer Gr<EFBFBD><EFBFBD>e von je 1 GB aufgeteilt, wodurch etwaige
   dateisystem-bedingte Beschr<EFBFBD>nkungen nicht relevant sind.
   
   Die maximale Tabellengr<EFBFBD><EFBFBD>e und die maximale Anzahl von Spalten k<EFBFBD>nnen
   vervierfacht werden, indem man die Default-Blockgr<EFBFBD><EFBFBD>e auf 32 KB
   heraufsetzt.
   
    4.6) Wieviel Plattenplatz wird ben<EFBFBD>tigt, um die Daten aus einer typischen
    Textdatei abzuspeichern?
    
   Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
   Textdatei bis zu f<EFBFBD>nfmal mehr Platz gegen<EFBFBD>ber der eigentlichen Gr<EFBFBD><EFBFBD>e
   der Datei beanspruchen.
   
   Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
   einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
   durchschnittliche L<EFBFBD>nge der Textbeschreibung 20 Byte betr<EFBFBD>gt. Die
   einfache Datei w<EFBFBD>rde 2,8 MB gro<EFBFBD> sein. Die Gr<EFBFBD><EFBFBD>e der
   PostgreSQL-Datenbankdatei, die diese Daten enth<EFBFBD>lt, liegt ungef<EFBFBD>hr bei
   6,4 MB:
    32 Bytes: jeder Zeilenkopf (ungef<EFBFBD>hr)
   +24 Bytes: ein Integer-Feld und ein Textfeld
   + 4 Bytes: Zeiger auf der Datenseite auf den Tupel
   -----------------------------------------------
    60 Bytes pro Zeile

   Die Gr<EFBFBD><EFBFBD>e einer Datenseite in PostgreSQL betr<EFBFBD>gt 8192 Bytes (8 KB),
   also:
   8192 Bytes pro Seite
   ---------------------   =  136 Zeilen pro Seite (abgerundet)
     64 Bytes pro Zeile

   100.000 Datenzeilen
   ------------------------  =  735 Datenbankseiten (aufgerundet)
       128 Zeilen pro Seite

   735 Datenbankseiten * 8192 Bytes pro Seite  =  6.021.120 Byte (6 MB)

   Indizes beanspruchen nicht so viel Platz. Da sie jedoch die Daten
   beinhalten, die sie indizieren, k<EFBFBD>nnen auch sie sehr gro<EFBFBD> werden.
   
   NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
   Platz in Anspruch nehmen.
   
    4.7) Meine Abfragen sind langsam oder benutzen die Indizes nicht. Warum?
    
   Indizes werden nicht automatisch bei jeder Abfrage verwendet. Indizes
   werden nur dann verwendet, wenn die abzufragende Tabelle eine
   bestimmte Gr<EFBFBD><EFBFBD>e <EFBFBD>bersteigt, und die Abfrage nur eine kleine
   Prozentzahl der Tabellenzeilen abfragt. Der Grund hierf<EFBFBD>r ist der,
   dass die durch einen Index verursachten Festplattenzugriffe manchmal
   l<EFBFBD>nger dauern w<EFBFBD>rden als ein einfaches Auslesen aller Tabellenzeilen
   (sequentieller Scan).
   
   Um festzustellen, ob ein Index verwendet werden soll, braucht
   PostgreSQL Statistiken <EFBFBD>ber die Tabelle. Diese Statistiken werden
   durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
   der Statistiken kennt der Abfragenoptimierer die Anzahl der
   Tabellenzeilen und kann besser entscheiden, ob Indizes verwendet
   werden sollen. Statistiken sind auch bei der Ermittlung der optimalen
   JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
   regelm<EFBFBD>ssig durchgef<EFBFBD>hrt werden, da sich der Inhalt einer Tabelle ja
   auch ver<EFBFBD>ndert
   
   In Versionen vor 8.0 werden Indizes oft nicht benutzt, wenn die
   jeweiligen Datentypen nicht genau <EFBFBD>bereinstimmen. Dies gilt besonders
   f<EFBFBD>r Spalten mit numerischen und Integer-Werten.
   
   Indizes werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
   verwendet. Ein sequentieller Scan mit anschlie<EFBFBD>endem explizitem
   Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
   gro<EFBFBD>en Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
   mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
   kleiner Abschnitt der Tabelle zur<EFBFBD>ckgeliefert wird. Dadurch wird es
   auch m<EFBFBD>glich, die Minimal- und Maximalwerte einer Abfrage unter
   Verwendung von Indizes zu ermitteln:
       SELECT spalte
         FROM tabelle
     ORDER BY spalte [ DESC ]
        LIMIT 1

   (Die Aggregatfunktionen MIN() und MAX() verwenden keine Indizes).
   
   Sollte es danach aussehen, also ob der Optimierer irrt<EFBFBD>mlich einen
   sequentiellen Scan ausf<EFBFBD>hrt, f<EFBFBD>hren Sie SET enable_seqscan TO 'off'
   aus und pr<EFBFBD>fen Sie, ob die Indexabfrage dadurch scheller geworden ist.
   
   Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, k<EFBFBD>nnen
   Indizes nur unter bestimmten Umst<EFBFBD>nden verwendet werden:
     * Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
          + LIKE-Suchmuster d<EFBFBD>rfen nicht mit % anfangen;
          + ~ (regul<EFBFBD>re Ausdr<EFBFBD>cke) m<EFBFBD>ssen mit ^ anfangen.
     * Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e])
       beginnen.
       
   Suchmuster, die Gross- und Kleinschreibung nicht ber<EFBFBD>cksichtigen (z.B.
   ILIKE bzw. ~*), verwenden keine Indizes. Stattdessen k<EFBFBD>nnen
   funktionale Indizes verwendet werden, die im Punkt 4.12 beschrieben
   werden.
   
   Die Standard-Locale "C" muss w<EFBFBD>hrend der Datenbank-Initialisierung mit
   initdb verwendet worden sein, da andere locales den n<EFBFBD>chstgr<EFBFBD><EFBFBD>ten Wert
   nicht ermitteln k<EFBFBD>nnen. Es ist allerdings m<EFBFBD>glich, einen besonderen
   text_pattern_ops-Index f<EFBFBD>r solche F<EFBFBD>lle zu erstellen.
   
    4.8) Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine
    Abfrage auswertet?
    
   Vgl. die EXPLAIN Man-Page.
   
    4.9) Was ist ein R-Tree Index?
    
   Ein R-Tree Index wird benutzt, um r<EFBFBD>umliche Daten zu indizieren. Ein
   Hash-Index kann nicht f<EFBFBD>r Bereichssuchen genutzt werden. Ein B-Tree
   Index kann nur f<EFBFBD>r Bereichssuchen in eindimensionalen Daten genutzt
   werden. R-Trees k<EFBFBD>nnen hingegen auch mit multi-dimensionalen Daten
   umgehen. Ein Beispiel: Wenn ein R-Tree Index auf ein Attribut vom Typ
   POINT gebildet wird, dann kann das System Abfragen wie z.B. "Zeige
   alle Punkte, die sich in einem umgebenden Rechteck befinden"
   effizienter beantworten.
   
   Die kanonische Ver<EFBFBD>ffentlichung, die das originale R-Tree Design
   beschreibt, ist:
   
   Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial
   Searching." Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data,
   45-57.
   
   Sie k<EFBFBD>nnen dieses Werk auch in Stonebrakers "Readings in Database
   Systems" finden.
   
   Die eingebauten R-Trees k<EFBFBD>nnen Polygone und Rechtecke verarbeiten.
   Theoretisch k<EFBFBD>nnen R-Trees auf eine hohe Anzahl von Dimensionen
   erweitert werden. F<EFBFBD>r die Praxis bedeutet eine solche Erweiterung
   allerdings eine Menge Arbeit und wir haben derzeit keinerlei
   Dokumentation dar<EFBFBD>ber, wie das zu machen w<EFBFBD>re.
   
    4.10) Was ist der "Genetic Query Optimizer"?
    
   Das GEQO-Modul in PostgreSQL soll dazu dienen, das Optimierungsproblem
   beim JOIN von vielen Tabellen auf der Basis genetischer Algorithmen
   (GA) zu l<EFBFBD>sen. Es erm<EFBFBD>glicht die Behandlung von gro<EFBFBD>en JOIN-Queries
   durch eine nicht-ersch<EFBFBD>pfende Suche.
   
    4.11) Wie verfahre ich bei der Suche mit regul<EFBFBD>ren Ausdr<EFBFBD>cken und bei einer
    Suche, bei der Gro<EFBFBD>- und Kleinschreibweisen ignoriert werden? Wie verwende
    ich einen Index bei solchen Suchabfragen?
    
   Der Operator ~ wendet einen regul<EFBFBD>ren Ausdruck an und ~* wendet ihn
   an, ohne die Gro<EFBFBD>- und Kleinschreibung zu beachten. Ebenso beachtet
   LIKE die Gro<EFBFBD>- und Kleinschreibung, und ILIKE nicht.
   
   Gleichheitsvergleiche, die Gro<EFBFBD>- und Kleinschreibung ignorieren,
   werden in der Regel so ausgedruckt:
      SELECT *
        FROM tabelle
       WHERE LOWER(spalte) = 'abc'

   Hier kann kein normaler Index benutzt werden. Legt man hingegen einen
   funktionalen Index an, so wird er auf jeden Fall verwendet:
      CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

    4.12) Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist?
    
   Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
   
    4.13) Was ist der Unterschied zwischen den verschiedenen CHAR-Typen?
    
Typ           interner Name   Bemerkungen
-------------------------------------------------
VARCHAR(n)    varchar         die Gr<EFBFBD><EFBFBD>e legt die Maximall<EFBFBD>nge fest; kein
                              Auff<EFBFBD>llen mit Leerzeichen
CHAR(n)       bpchar          mit Leerzeichen gef<EFBFBD>llt bis zur angegebenen L<EFBFBD>nge
TEXT          text            keine obere Schranke f<EFBFBD>r die L<EFBFBD>nge
BYTEA         bytea           Bytearray mit variabler L<EFBFBD>nge (auch f<EFBFBD>r
                              '\0'-Bytes geeignet)
"char"        char            1 Zeichen

   Der interne Name kommt vor allem in den Systemkatalogen und in manchen
   Fehlermeldungen vor.
   
   Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
   geben die L<EFBFBD>nge an, gefolgt von den Daten). Daher ist der tats<EFBFBD>chlich
   belegte Platz immer etwas mehr als die deklarierte Feldgr<EFBFBD><EFBFBD>e.
   Allerdings wird unter Umst<EFBFBD>nden auf diese Datentypen Datenkompression
   durch das TOAST- Verfahren angewendet, womit der tats<EFBFBD>chlich belegte
   Platz auch geringer als erwartet ausfallen kann.
   
   F<EFBFBD>r die Speicherung von Zeichenketten variabler L<EFBFBD>nge empfiehlt sich
   VARCHAR(n). Die maximale L<EFBFBD>nge eines VARCHAR(n)-Felds wird bei der
   Tabellendefinition festgelegt. TEXT setzt keine L<EFBFBD>ngengrenze,
   allerdings gibt es eine systembedingte Obergrenze von 1 GB.
   
   CHAR(n) ist geeignet f<EFBFBD>r die Speicherung von Zeichenketten, die alle
   die gleiche L<EFBFBD>nge haben. Bitte beachten Sie, dass CHAR(n) automatisch
   Zeichenketten bis zur definierten Feldl<EFBFBD>nge mit Leerzeichen ausf<EFBFBD>llt,
   w<EFBFBD>hrend bei VARCHAR(n) nur die tats<EFBFBD>chlich eingegebene Zeichenkette
   gespeichert wird.
   
   BYTEA ist f<EFBFBD>r bin<EFBFBD>re Daten, besonders f<EFBFBD>r Werte, die NULL-Bytes haben.
   
   Alle der hier erw<EFBFBD>hnten Typen weisen <EFBFBD>hnliche Performanzeigenschaften
   auf.
   
    4.14.1) Wie erzeuge ich ein serielles Feld mit automatischer Erh<EFBFBD>hung des
    Werts (serial/auto-increment)?
    
   PostgreSQL bietet einen SERIAL-Datentyp. Dieser erzeugt automatisch
   eine Sequenz auf die angegebene Spalte. Zum Beispiel:
      CREATE TABLE person (
          id   SERIAL,
          name TEXT
      )

   wird automatisch in:
      CREATE SEQUENCE person_id_seq;
      CREATE TABLE person (
        id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
        name TEXT
      );

   umgewandelt.
   
   Die create_sequence Man-Page liefert weitere Informationen <EFBFBD>ber
   Sequenzen. Es ist auch m<EFBFBD>glich, den OID-Wert jeder Spalte als
   einmaligen Wert einzusetzen. Sollten Sie allerdings die Datenbank
   exportieren und reimportieren wollen, m<EFBFBD>ssen Sie die Option -o von
   pg_dump bzw. COPY WITH OIDS verwenden, um die OIDs beizubehalten.
   
    4.14.2) Wie bekomme ich den Wert einer SERIAL-Sequenz?
    
   Eine M<EFBFBD>glichkeit w<EFBFBD>re, mit der nextval()-Funktion den n<EFBFBD>chsten
   SERIAL-Wert von dem Sequenzobjekt vor der Auszuf<EFBFBD>hrung einer
   INSERT-Anweisung anzufordern und ihn dann explizit in die
   INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.14.1
   k<EFBFBD>nnte dieser Vorgang in einer Pseudosprache so aussehen:
    new_id = output of execute("SELECT nextval('person_id_seq')");
    execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

   Danach st<EFBFBD>nde der neue Wert in der Variablen new_id f<EFBFBD>r die Verwendung
   in weiteren Abfragen zur Verf<EFBFBD>gung, zum Beispiel als Fremdschl<EFBFBD>ssel
   zur Tabelle 'person'). Bitte beachten Sie, dass der Name des
   automatisch erstellten SEQUENCE-Objektes folgenden Name hat:
   <table>_<serialcolumn>_seq wobei 'table' und 'serialcolumn' die Namen
   der jeweils betreffenden Tabelle / Spalte darstellen.
   
   Als weitere M<EFBFBD>glichkeit k<EFBFBD>nnen Sie nach einer INSERT-Anweisung den
   automatisch eingef<EFBFBD>gten SERIAL-Wert mit der currval()-Funktion
   zur<EFBFBD>ckgeben lassen:
    execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
    new_id = output of execute("SELECT currval('person_id_seq')");

   Schlie<EFBFBD>lich besteht noch die M<EFBFBD>glichkeit, den von einer
   INSERT-Anweisung zur<EFBFBD>ckgelieferten OID-Wert als einmaligen Wert zu
   verwenden. Dieser Ansatz ist allerdings PostgreSQL-spezifisch;
   au<EFBFBD>erdem wird nach ca. 4 Milliarden Eintr<EFBFBD>gen der OID-Wert wieder auf
   eine kleine Zahl gesetzt, ist also nicht garantiert immer einmalig
   oder aufsteigend.
   
   Mit zum Beispiel dem DBD::Pg-Modul von Perl wird der OID-Wert nach
   einem $sth->excute() <EFBFBD>ber $sth->{pg_oid_status} zur<EFBFBD>ckgeliefert.
   
    4.14.3) F<EFBFBD>hren currval() und nextval() zu einer Race-Condition mit anderen
    Nutzern?
    
   Nein. currval() liefert einen Wert zur<EFBFBD>ck, der von Ihrem Backend
   bestimmt wird, und der anderen Benutzern nicht zur Verf<EFBFBD>gung steht.
   
    4.14.4) Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht
    zur<EFBFBD>ckgesetzt? Warum gibt es L<EFBFBD>cken in der Nummerierung meiner
    Sequenz-/SERIAL-Spalte?
    
   Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
   werden Sequenzen gerade nicht f<EFBFBD>r andere Transaktionen gesperrt,
   sondern die Sequenznummern werden den laufenden Transaktionen sofort
   zugeteilt. L<EFBFBD>cken in der Sequenznummerierung werden durch abgebrochene
   Transaktionen verursacht.
   
    4.15) Was ist ein OID? Was ist ein TID?
    
   OIDs sind PostgreSQLs Antwort auf eindeutige Zeilen-IDs. Jede Zeile,
   die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID. Alle
   OIDs, die durch initdb erzeugt werden, sind kleiner als 16384 (siehe
   include/access/transam.h). Alle OIDs, die durch den Benutzer erzeugt
   werden, sind gr<EFBFBD><EFBFBD>er oder gleich diesem Wert. Standardm<EFBFBD><EFBFBD>ig sind all
   OIDs nicht nur innerhalb einer Tabelle oder Datenbank, sondern in der
   gesamten PostgreSQL-Installation einmalig.
   
   PostgreSQL benutzt OIDs in seinen internen Systemtabellen, um Zeilen
   in JOINs zwischen Tabellen zu verkn<EFBFBD>pfen. Es ist m<EFBFBD>glich, einen Index
   f<EFBFBD>r die OID-Spalte zu erstellen, wodurch schnellere Zugriffszeiten
   erreicht werden k<EFBFBD>nnen. Es wird empfohlen, OID-Werte in Spalten vom
   Typ OID zu speichern.
   
   OIDs werden allen neuen Zeilen von einem zentralen Bereich, der von
   allen Datenbanken genutzt wird, zugewiesen. Nichts hindert Sie daran,
   die OID zu <EFBFBD>ndern, oder eine Kopie der Tabelle mit den originalen OIDs
   anzulegen:
        CREATE TABLE new_table(mycol int);
        SELECT oid AS old_oid, mycol INTO tmp_table FROM old_table;
        COPY tmp_table TO '/tmp/pgtable';
        COPY new_table WITH OIDS FROM '/tmp/pgtable';
        DROP TABLE tmp_table;

   OIDs werden als 4-Byte Integer gespeichert und laufen bei einem Wert
   von ungef<EFBFBD>hr 4 Milliarden <EFBFBD>ber. Niemand hat jemals davon berichtet,
   dass dies passiert w<EFBFBD>re aber wir haben geplant, diese Beschr<EFBFBD>nkung
   aufzuheben, bevor das jemand ausprobieren kann.
   
   TIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und
   Offset Werte zu identifizieren. TIDs ver<EFBFBD>ndern sich, sobald Zeilen
   ver<EFBFBD>ndert oder zur<EFBFBD>ckgeladen werden. Sie werden in Indexeintr<EFBFBD>gen
   benutzt um auf die physikalischen Zeilen zu zeigen.
   
    4.16) Welche Bedeutung haben die verschiedenen Ausdr<EFBFBD>cke, die in PostgreSQL
    benutzt werden (z.B. attribute, class,...)?
    
   Einige der Quelltexte und die <EFBFBD>ltere Dokumentation nutzen allgemeine
   Begriffe. Hier sind einige aufgef<EFBFBD>hrt:
     * row, record, tuple
     * attribute, field, column
     * table, class
     * retrieve, SELECT
     * replace, UPDATE
     * append, INSERT
     * OID, serial value
     * portal, cursor
     * range variable, table name, table alias
       
   Eine allgemeine Liste der Datenbank-Terminologie erhalten Sie hier:
   http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
   /glossary.html (engl.).
   
    4.17) Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in
    AllocSetAlloc()"?
    
   Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
   oder Ihr Kernel hat niedrige H<EFBFBD>chstgrenzen f<EFBFBD>r bestimmte Ressourcen.
   Probieren Sie vor dem Start von postmaster folgendes:
      ulimit -d 262144
      limit datasize 256m

   Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
   ausgef<EFBFBD>hrt werden. Auf jedem Fall wird die Grenze des Datensegments
   f<EFBFBD>r Prozesse erh<EFBFBD>ht werden und eventuell die erfolgreiche Ausf<EFBFBD>hrung
   der Abfrage erm<EFBFBD>glichen. Falls Sie ein Problem mit dem SQL-CLient
   haben, weil das Backend zu viele Daten zur<EFBFBD>ckliefert, versuchen Sie
   dies vor dem Start des SQL-Clients.
   
    4.18) Wie kann ich feststellen, welche PostgreSQL-Version bei mir l<EFBFBD>uft?
    
   Geben Sie in psql SELECT VERSION(); ein.
   
    4.19) Bei "large-object"-Operationen kommt die Fehlermeldung: "invalid
    large obj descriptor". Warum?
    
   Sie sollten die Anweisungen BEGIN WORK und COMMIT bei jeden Gebrauch
   von Large Objects benutzen. Also um lo_open ... lo_close.
   
   Derzeit erzwingt PostgreSQL diese Regel, indem es die Handles der
   Large Objects beim COMMIT der Transaktion schlie<EFBFBD>t. So f<EFBFBD>hrt der erste
   Versuch, etwas mit dem Large Object zu machen, zu einer Meldung
   "invalid large obj descriptor". Solange Sie keine Transaktionen
   benutzen, wird der Code, der in <EFBFBD>lteren PostgreSQL-Versionen
   funktionierte, nun diese Fehlermeldung erzeugen.
   
   Falls Sie eine Client-Schnittstelle wie ODBC benutzen, kann es sein,
   dass die auto-commit-Option ausgeschaltet werden muss.
   
    4.20) Wie kann ich eine Spalte erstellen, deren Default-Wert immer die
    aktuelle Uhrzeit enthalten soll?
    
   Dazu verwenden Sie CURRENT_TIMESTAMP:
      CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );

    4.21) Warum sind meine Unterabfragen (subqueries), die IN verwenden, so
    langsam?
    
   In Versionen vor 7.4 werden Unterabfragen mit der <EFBFBD>usseren Abfrage
   verbunden, in dem f<EFBFBD>r jede Reihe der <EFBFBD>usseren Query die Ergebnisse der
   Unterabfrage sequentiell gepr<EFBFBD>ft werden. Um dies zu vermeiden, kann
   man IN durch EXISTS ersetzen, z.B.:
      SELECT *
        FROM tabelle_1
       WHERE spalte1 IN (SELECT spalte2 FROM tabelle_2)

   ersetzen durch:
      SELECT *
        FROM tabelle_1
       WHERE EXISTS (SELECT spalte2 FROM tabelle_2 WHERE spalte1 = spalte2)

   Damit diese Abfrage effizient durchgef<EFBFBD>hrt wird, sollte f<EFBFBD>r 'spalte2'
   ein Index angelegt worden sein. Ab PostgreSQL 7.4 verwendet IN die
   gleichen Methoden wie die normale Tabellenverkn<EFBFBD>pfung und ist daher
   soger EXISTS vorzuziehen.
   
    4.22) Wie f<EFBFBD>hre ich einen OUTER JOIN durch?
    
   PostgreSQL ab der Version 7.1 unterst<EFBFBD>tzt OUTER JOINs nach dem SQL-
   Standardsyntax. Hier zwei Beispiele:
      SELECT *
        FROM tabelle_1 t1
             LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

   bzw.:
      SELECT *
        FROM tabelle_1 t1
             LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

   Diese identischen Abfragen verkn<EFBFBD>pfen tabelle_1 mit tabelle_2 <EFBFBD>ber die
   Spalte 'spalte' und geben au<EFBFBD>erdem alle unverkn<EFBFBD>pften Zeilen in
   tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
   zur<EFBFBD>ck. Ein RIGHT JOIN w<EFBFBD>rde hingegen alle unverkn<EFBFBD>pften Zeilen in
   tabelle_2 hinzuf<EFBFBD>gen und ein FULL JOIN w<EFBFBD>rde alle verkn<EFBFBD>pften Zeilen
   sowie jeweils alle unverkn<EFBFBD>pften Zeilen aus den beiden Tabellen
   zur<EFBFBD>ckliefern. Die Angabe von OUTER ist nicht zwingend und kann in
   LEFT, RIGHT und FULL-Verkn<EFBFBD>pfungen weggelassen werden. Normale
   Verkn<EFBFBD>pfungen sind INNER JOINs.
   
   In fr<EFBFBD>heren Versionen von PostgreSQL konnten OUTER JOINs mittels UNION
   und NOT IN simuliert werden. Zum Beispiel 'tabelle_1' und 'tabelle_2'
   k<EFBFBD>nnen als LEFT OUTER JOIN auch so verkn<EFBFBD>pft werden:
      SELECT t1.spalte1, t2.spalte2
        FROM tabelle_1 t1, tabelle_2 t2
       WHERE t1.spalte1 = t2.spalte1
       UNION ALL
      SELECT t1.spalte1, NULL
        FROM tabelle_1 t1
       WHERE t1.spalte1 NOT IN (SELECT t2.spalte1 FROM tabelle_2 t2)
       ORDER BY spalte1

    4.23) Wie kann ich Abfragen <EFBFBD>ber mehrere Datenbanken hinweg ausf<EFBFBD>hren?
    
   Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
   Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
   Systemkataloge l<EFBFBD>dt, ist eine datenbank<EFBFBD>bergreifende Abfrage nicht
   m<EFBFBD>glich.
   
   contrib/dblink ist eine Erweiterung, die datenbank<EFBFBD>bergreifende
   Abfragen <EFBFBD>ber Funktionsaufrufe erm<EFBFBD>glicht.
   
   Es ist nat<EFBFBD>rlich m<EFBFBD>glich, dass eine Client-Anwendung gleichzeitige
   Verbindungen zu verschiedenen Datenbanken aufbaut und selber
   Datens<EFBFBD>tze zusammenf<EFBFBD>gt.
   
   Ab 7.3 unterst<EFBFBD>tzt PostgreSQL schemas, die die Aufteilung einer
   Datenbank in mehrere logische Bereiche erm<EFBFBD>glichen. Bei vielen
   Anwendungen k<EFBFBD>nnten diese einen geeigneten Ersatz f<EFBFBD>r den Zugriff auf
   eine andere Datenbank bieten.
   
    4.24) Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion
    zur<EFBFBD>ckgeben lassen?
    
   Ab 7.3 k<EFBFBD>nnen Funktionen mehrere Zeilen und Spalten zur<EFBFBD>ckgeben, vgl.:
   http://techdocs.postgresql.org/guides/SetReturningFunctions.
   
    4.25) Warum kann ich tempor<EFBFBD>re Tabellen in PL/PgSQL-Funktionen nicht
    zuverl<EFBFBD>ssig erstellen bzw. l<EFBFBD>schen?
    
   PL/PgSQL verarbeitet die Inhalte einer Funktion in eine Cache. Dies
   hat eine unangenehme Nebenwirkung, n<EFBFBD>mlich dass wenn eine PL/PgSQL-
   Funktion auf eine tempor<EFBFBD>re Tabelle zugreift, und diese Tabelle
   anschlie<EFBFBD>end gel<EFBFBD>scht bzw. neu erstellt wird, die Funktion
   fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
   tempor<EFBFBD>re Tabelle zeigen.
   
   Die L<EFBFBD>sung f<EFBFBD>r diese Probleme besteht darin, in der PL/PgSQL Funktion
   mittels EXECUTE auf tempor<EFBFBD>re Tabellen zuzugreifen. Diese bewirkt,
   dass bei jedem Funktionsruf die betreffende Abfrage neu geparst wird.
   
    4.26) Welche M<EFBFBD>glichkeiten zur Verschl<EFBFBD>sselung gibt es?
    
     * contrib/pgcrypto enth<EFBFBD>lt diverse Funktionen f<EFBFBD>r die Ben<EFBFBD>tzung mit
       SQL-Abfragen.
     * Um Verbindungen zwischen dem Server und Client-Anwendungen zu
       verschl<EFBFBD>sseln, muss in der Server-Konfigurationsdatei
       postgresql.conf die ssl-Option auf true (Voreinstellung: false)
       gesetzt werden und ein passender host- bzw. hostssl-Eintrag muss
       in pg_hba.conf vorhanden sein. Zudem muss die sslmode-Einstellung
       beim Client nicht auf disable gesetzt werden. (Bitte beachten Sie
       auch, da<EFBFBD> neben der eingebauten SSL-Unterst<EFBFBD>tzung verschl<EFBFBD>sselte
       Verbindungen auch <EFBFBD>ber externe Anwendungen wie stunnel oder ssh
       aufgebaut werden k<EFBFBD>nnen).
     * Die Passw<EFBFBD>rter der Datenbanknutzer werden ab Version 7.3
       automatisch verschl<EFBFBD>sselt (in fr<EFBFBD>heren Versionen mu<EFBFBD> der Parameter
       PASSWORD_ENCRYPTION in postgresql.conf explizit eingeschaltet
       werden).
     * Betrieb des Servers auf einem verschl<EFBFBD>sselten Dateisystem.
     _________________________________________________________________
   
                            PostgreSQL erweitern
                                      
    5.1) Ich habe eine benutzerdefinierte Funktion geschrieben. Wenn ich sie in
    psql aufrufe, kommt ein core dump. Warum?
    
   Dieses Problem kann viele Ursachen haben. Testen Sie Ihre Funktion
   zuerst in einem eigenen Testprogramm.
   
    5.2) Wie kann ich praktische neue Typen und Funktionen zu PostgreSQL
    hinzuf<EFBFBD>gen?
    
   Senden Sie Ihre Beitr<EFBFBD>ge an die Mailing Liste pgsql-hackers, und sie
   werden nach Pr<EFBFBD>fung eventuell ins contrib/ Verzeichnis des Quellcodes
   aufgenommen werden.
   
    5.3) Wie schreibe ich eine Funktion in C, die einen Tupel zur<EFBFBD>ckliefert?
    
   Ab PostgreSQL 7.3 werden Funktionen, die Tupel zur<EFBFBD>ckliefern, in C,
   PL/PgSQL und SQL unterst<EFBFBD>tzt. Der Programmer's Guide enth<EFBFBD>lt weitere
   Informationen dazu. Ein Bespiel einer solchen Funktion befindet sich
   in contrib/tablefunc.
   
    5.4) Ich habe eine der Quellendateien ge<EFBFBD>ndert. Warum macht sich die
    <EFBFBD>nderung beim erneuten Kompilieren nicht bemerkbar?
    
   Die Makefiles enthalten nicht die richtigen Abh<EFBFBD>ngigkeiten f<EFBFBD>r
   include- Dateien. Sie m<EFBFBD>ssen ein "make clean" und dann ein weiteres
   "make" ausf<EFBFBD>hren. Wenn Sie gcc benutzen, k<EFBFBD>nnen Sie die
   "--enable-depend"-Option des configure- Skripts benutzen, damit der
   Compiler die Abh<EFBFBD>ngigkeiten automatisch ermittelt.
     _________________________________________________________________
   
    Anmerkungen des <EFBFBD>bersetzers
    
   Die englische Vorlage dieser FAQ wird st<EFBFBD>ndig <EFBFBD>berarbeitet. Daher
   liegt die <EFBFBD>bersetzung nicht immer auf dem aktuellsten Stand.
   
   Die aktuellste Version der deutschen <EFBFBD>bersetzung befindet sich immer
   unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
   "Arbeitsversion" enth<EFBFBD>lt eventuell <EFBFBD>nderungen, die noch nicht auf der
   PostgreSQL-Website eingebunden worden sind.
   
   <EFBFBD>ber Verbesserungshinweise und Korrekturvorschl<EFBFBD>ge sowie
   Verst<EFBFBD>ndnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
   allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
   die Mailing-Listen als schnelle und zuverl<EFBFBD>ssige Anlaufstellen.