
                   Foire Aux Questions (FAQ) pour PostgreSQL
                                       
   Dernière mise à jour : vendredi 11 juillet 2004 23:58:24
   
   Mainteneur actuel : Bruce Momjian (pgman@candle.pha.pa.us)
   
   La plus récente version de ce document est disponible sur
   http://www.PostgreSQL.org/docs/faqs/FAQ.html.
   
   Les questions spécifiques à la plateforme sont répondues sur
   http://www.PostgreSQL.org/docs/index.html.
     _________________________________________________________________
   
                            Questions générales
                                      
   1.1) Qu'est ce que PostgreSQL ? Comment le prononcer ?
   1.2) Quelle est la licence de PostgreSQL ?
   1.3) Sous quels environnements Unix PostgreSQL tourne-t-il ?
   1.4) Sous quels environnements non-Unix PostgreSQL tourne-t-il ?
   1.5) Où puis-je me procurer PostgreSQL ?
   1.6) Où puis-je obtenir du support ?
   1.7) Quelle est la dernière version ?
   1.8) Quelle documentation est disponible ?
   1.9) Comment savoir quels sont les bogues connus ou les
   fonctionnalités manquantes ?
   1.10) Comment puis-je apprendre le SQL ?
   1.11) PostgreSQL est-il compatible an 2000 ?
   1.12) Comment puis-je rejoindre l'équipe de développement ?
   1.13) Comment dois-je soumettre un rapport de bogue ?
   1.14) Comment PostgreSQL se compare-t'il à d'autres SGBD ?
   1.15) Comment puis-je aider financièrement PostgreSQL ?
   
                    Questions sur le client utilisateur
                                      
   2.1) Y a-t-il des pilotes ODBC pour PostgreSQL ?
   2.2) Quels outils sont disponibles pour utiliser PostgreSQL avec des
   pages Web ?
   2.3) PostgreSQL a-t-il une interface graphique ?
   2.4) Quels langages sont disponibles pour communiquer avec
   PostgreSQL ?
   
                         Questions administratives
                                      
   3.1) Comment installer PostgreSQL ailleurs que sous /usr/local/pgsql ?
   3.2) Quand je lance postmaster, j'obtiens un Bad System Call ou un
   message core dumped. Pourquoi ?
   3.3) Quand je lance postmaster, j'obtiens des erreurs IpcMemoryCreate.
   Pourquoi ?
   3.4) Quand je lance postmaster, j'obtiens des erreurs
   IpcSemaphoreCreate. Pourquoi ?
   3.5) Comment contrôler les connexions d'autres machines ?
   3.6) Comment règler le moteur de la base de données pour de meilleures
   performances ?
   3.7) Quelles fonctionalités de déboguage sont disponibles ?
   3.8) Pourquoi est-ce que j'obtiens des messages Sorry, too many
   clients quand je me connecte ?
   3.9) Que contient le répertoire pgsql_tmp ?
   3.10) Pourquoi ai-je besoin de faire une sauvegarde des bases et de
   restaurer pour mettre a jour les versions de PostgreSQL ?
   3.11) Quels matériels dois-je utiliser ?
   
                          Questions fonctionnelles
                                      
   4.1) Quelle est la différence entre curseur binaire et curseur
   normal ?
   4.2) Comment faire un SELECT seulement sur les premières lignes d'une
   requête ? Sur une ligne aléatoire ?
   4.3) Comment obtenir une liste des tables ou d'autres choses que je
   vois dans psql ?
   4.4) Comment supprime-t-on une colonne d'une table, ou comment
   change-t-on son type de données ?
   4.5) Quelle est la taille maximale pour une ligne, une table et une
   base de données ?
   4.6) Combien d'espace disque faut-il pour stocker les données d'un
   fichier texte typique ?
   4.7) Comment puis-je savoir quels index, tables, bases de données et
   utilisateurs sont définis ?
   4.8) Mes requêtes sont lentes ou ne font pas usage des index.
   Pourquoi ?
   4.9) Comment puis-je savoir si l'optimiseur évalue mes requêtes ?
   4.10) Qu'est-ce qu'un index R-tree ?
   4.11) Qu'est-ce que l'optimiseur génétique de requêtes ?
   4.12) Comment puis-je réaliser des recherches par des expressions
   rationnelles ainsi que des recherches non sensibles à la casse ?
   Comment puis-je utiliser un index lors de recherches non sensibles à
   la casse ?
   4.13) Comment puis-je détecter si un champ est NULL dans une requête ?
   4.14) Quelle sont les différences entre les nombreux types de
   caractères ?
   4.15.1) Comment puis-je créer un champ série, c'est-à-dire
   s'incrémentant automatiquement ?
   4.15.2) Comment puis-je obtenir la valeur d'un SERIAL suite à une
   insertion ?
   4.15.3) Est-ce que currval() et nextval() n'amènent pas des problèmes
   lorsque plusieurs utilisateurs les lancent en même temps ?
   4.15.4) Pourquoi mes numéros de séquences ne sont pas ré-utilisés lors
   d'une annulation de transaction ? Pourquoi existe-t'il des trous dans
   la numérotation de ma colonne séquentielle (SERIAL) ?
   4.16) Qu'est-ce qu'un OID? Qu'est-ce qu'un TID ?
   4.17) A quoi correspond certains termes utilisés avec PostgreSQL ?
   4.18) Pourquoi ai-je l'erreur ERROR: Memory exhausted in
   AllocSetAlloc() ?
   4.19) Comment puis-je connaître la version de PostgreSQL que
   j'utilise ?
   4.20) Pourquoi ai-je invalid large obj descriptor lors d'opérations
   avec des gros objets ?
   4.21) Comment puis-je créer une colonne qui aura par défaut l'heure
   actuelle comme valeur ?
   4.22) Pourquoi mes sous-requêtes utilisant IN sont-elles si lentes ?
   4.23) Comment puis-je réaliser une jointure externe ?
   4.24) Comment puis-je lancer des requêtes utilisant plusieurs bases de
   données ??
   4.25) Comment puis-je renvoyer plusieurs lignes ou colonnes à partir
   d'une fonction ?
   4.26) Why can't I reliably create/drop temporary tables in PL/PgSQL
   functions?
   4.27) Quelles options de replication sont disponibles ?
   4.28) Quelles options de cryptage sont disponibles ?
   
                             Etendre PostgreSQL
                                      
   5.1) J'ai écrit une fonction utilisateur. Lorsque je l'exécute avec
   psql, pourquoi cela finit-il avec un "dump core" ?
   5.2) Comment puis-je contribuer avec de nouveaux types et fonctions
   pour PostgreSQL ?
   5.3) Comment puis-je écrire une fonction C pour récupérer une ligne ?
   5.4) J'ai modifié un fichier source. Pourquoi la modification
   n'est-elle pas visible après la recompilation ?
     _________________________________________________________________
   
                            Questions générales
                                      
    1.1) Qu'est ce que PostgreSQL ? Comment le prononcer ?
    
   PostgreSQL se prononce Post-Gres-Q-L. Un fichier audio est disponible
   sur http://www.postgresql.org/postgresql.mp3 pour ceux souhaitant
   entendre la prononciation.
   
   PostgreSQL est une amélioration du système de gestion de bases de
   données POSTGRES (et est toujours quelque fois appelé "Postgres"), un
   prototype de recherche de SGBD de prochaine génération. PostgreSQL
   garde le puissant modèle de données et les types de données riches de
   POSTGRES, mais remplace le langage de requêtes PostQuel par un
   sous-ensemble étendu de SQL. PostgreSQL est gratuit et les sources
   complets sont disponibles.
   
   PostgreSQL est écrit par une équipe de développeurs qui sont tous
   inscrits à la liste de diffusion de développement de PostgreSQL. Le
   coordinateur actuel est Marc G. Fournier (scrappy@PostgreSQL.org et
   voir la section 1.6 pour contacter les développeurs). Cette équipe est
   responsable de tout le développement de PostgreSQL. C'est un projet
   soutenu par une communauté sans être contrôlé par une société. Pour y
   contribuer, voir la FAQ des développeurs sur
   http://www.postgresql.org/docs/faqs/FAQ_DEV.html.
   
   Les auteurs de PostgreSQL 1.01 étaient Andrew Yu et Jolly Chen.
   Beaucoup d'autres personnes ont contribué au portage, aux tests, au
   déboguage et à l'amélioration du code. Le code de Postgres original,
   duquel PostgreSQL est dérivé, était le fruit de l'effort de nombreux
   étudiants diplômés et non diplômés, et de programmeurs travaillant
   sous la direction du Professeur Michael Stonebraker à l'université de
   Californie, Berkeley.
   
   Le nom original du logiciel à Berkeley était Postgres. Quand le SQL
   fut ajouté en 1995, le nom a dû être changé en Postgres95. Fin 1996,
   le nom fut changé en PostgreSQL.
   
    1.2) Quelle est la licence de PostgreSQL ?
    
   PostgreSQL est distribué sous la licence suivante :
   
   PostgreSQL Data Base Management System
   
   Portions copyright (c) 1996-2004, 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.
   
   La licence ci-dessus est la licence BSD, une licence open-source
   classique.
   
    1.3) Sous quels environnements Unix PostgreSQL tourne-t-il ?
    
   En général, tout environnement compatible Unix moderne devrait pouvoir
   faire fonctionner PostgreSQL. Les environnements qui ont été testés
   explicitement sont listés dans les instructions d'installation.
   
    1.4) Sous quels environnements non Unix PostgreSQL fonctionne-t'il ?
    
   Client
   
   Il est possible de compiler la bibliothèque C libpq, psql et d'autres
   interfaces et applications clientes pour qu'elles tournent sous des
   environnements MS Windows. Dans ce cas, le client tourne sous MS
   Windows et communique par TCP/IP avec un serveur tournant sous un
   environnement Unix supporté. Un fichier win32.mak est inclus dans la
   distribution pour construire une bibliothèque libpq psql Win32.
   PostgreSQL communique aussi avec des clients ODBC.
   
   Serveur
   
   Le serveur de base de données peut tourner sous Windows NT et Windows
   2000 en utilisant Cygwin, la bibliothèque de portage Unix/NT de
   Cygnus. Voir pgsql/doc/FAQ_MSWIN dans la distribution ou la FAQ MS
   Windows sur http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN.
   
   Un port natif sur MS Windows NT/2000/XP est en court. Pour plus de
   détails sur le statut actuel de PostgreSQL sur Windows, voir
   http://techdocs.postgresql.org/guides/Windows et
   http://momjian.postgresql.org/main/writings/pgsql/win32.html.
   
   Il existe aussi un port sur Novell Netware sur
   http://forge.novell.com.
   
    1.5) Où puis-je me procurer PostgreSQL ?
    
   Le site FTP anonyme principal de PostgreSQL est
   ftp://ftp.PostgreSQL.org/pub. Pour les sites miroirs, voir notre site
   web principal.
   
    1.6) Où puis-je obtenir du support ?
    
   La liste de diffusion principale est pgsql-general@PostgreSQL.org.
   Elle est disponible pour discuter de sujets en rapport avec
   PostgreSQL. Pour s'y inscrire, il faut envoyer un courriel avec les
   lignes suivantes dans le corps du message (pas dans la ligne du
   sujet) :
    subscribe
    end

   à pgsql-general-request@PostgreSQL.org.
   
   Il existe aussi un recueil de la liste. Pour s'y inscrire, envoyez un
   courriel à pgsql-general-digest-request@PostgreSQL.org avec dans le
   corps :
    subscribe
    end

   Les recueils sont envoyés aux membres de cette liste dès que la liste
   principale a reçu 30 Ko de messages.
   
   Une liste de diffusion de bogues est disponible. Pour s'y inscrire,
   envoyer un courriel à pgsql-bugs-request@PostgreSQL.org avec dans le
   corps :
    subscribe
    end

   Une liste de diffusion pour les développeurs est aussi disponible.
   Pour s'y inscrire, envoyez un courriel à
   pgsql-hackers-request@PostgreSQL.org avec dans le corps :
    subscribe
    end

   Vous pouvez trouver d'autres listes et informations sur PostgreSQL sur
   le site web de PostgreSQL :
   
     http://www.PostgreSQL.org
     
   Il y a aussi un canal IRC sur Freenode et EFNet, le canal #PostgreSQL.
   Vous pouvez utiliser la commande Unix irc -c '#PostgreSQL' "$USER"
   irc.phoenix.net ou irc -c '#PostgreSQL' "$USER" irc.freenode.net.
   
   Une liste de sociétés pouvant fournir un support commercial est
   disponible sur http://techdocs.postgresql.org/companies.php.
   
    1.7) Quelle est la dernière version ?
    
   La dernière version de PostgreSQL est la version 7.4.3.
   
   Nous projetons de sortir une version majeure tous les six à huit mois.
   
    1.8) Quelle documentation est disponible ?
    
   Plusieurs manuels, pages de manuel ainsi que des petits exemples de
   test sont inclus dans la distribution. Voir le répertoire /doc. Vous
   pouvez aussi accéder aux manuels en ligne sur
   http://www.PostgreSQL.org/docs.
   
   Deux livres sur PostgreSQL sont disponibles en ligne sur
   http://www.PostgreSQL.org/docs/awbook.html et
   http://www.commandprompt.com/ppbook/. Il y a une liste de livres sur
   PostgreSQL pouvant être achetés sur
   http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Il y a aussi
   une collection d'articles techniques sur PostgreSQL sur
   http://techdocs.PostgreSQL.org/.
   
   psql possède des commandes \d pratiques montrant des informations sur
   les types, opérateurs, fonctions, aggrégats, etc.
   
   Notre site web contient encore plus de documentations.
   
    1.9) Comment savoir quels sont les bogues connus ou les fonctionnalités
    manquantes ?
    
   PostgreSQL supporte un sous-ensemble étendu de SQL-92. Voir notre
   liste TODO pour les bogues connus, les fonctionnalités manquantes et
   les plans pour le futur.
   
    1.10) Comment puis-je apprendre le SQL ?
    
   Le livre PostgreSQL sur http://www.PostgreSQL.org/docs/awbook.html
   enseigne le SQL. Il existe un autre livre PostgreSQL sur
   http://www.commandprompt.com/ppbook. Il existe de bons tutoriels sur
   http://www.intermedia.net/support/sql/sqltut.shtm,
   http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
   et http://sqlcourse.com.
   
   Un autre (en anglais uniquement) "Teach Yourself SQL in 21 Days,
   Second Edition" se trouve sur
   http://members.tripod.com/er4ebus/sql/index.htm
   
   Nombre de nos utilisateurs aiment The Practical SQL Handbook, Bowman,
   Judith S., et al., Addison-Wesley. D'autres aiment The Complete
   Reference SQL, Groff et al., McGraw-Hill.
   
    1.11) PostgreSQL est-il compatible an 2000 ?
    
   Oui, nous manipulons facilement les dates après et avant l'an 2000.
   
    1.12) Comment puis-je rejoindre l'équipe de développement ?
    
   Tout d'abord, téléchargez les derniers sources et lisez la
   documentation pour les développeurs sur notre site web ou bien dans la
   distribution. Ensuite, inscrivez-vous aux listes de diffusion
   pgsql-hackers et pgsql-patches. Et pour finir, soumettez des
   correctifs de grande qualité sur pgsql-patches.
   
   Environ une douzaine de personnes ont des droits de modification sur
   l'archive CVS de PostgreSQL. Ils ont chacun soumis tellement de
   correctifs de qualité qu'il était devenu impossible aux développeurs
   de tenir la cadence et nous avions confiance dans le qualité des
   correctifs qu'ils soumettaient.
   
    1.13) Comment dois-je soumettre un rapport de bogue ?
    
   Merci de visiter la page PostgreSQL BugTool sur
   http://www.PostgreSQL.org/bugs/bugs.php, qui donne des indications sur
   la façon de soumettre un rapport de bogue.
   
   De même, vérifiez notre site ftp ftp://ftp.PostgreSQL.org/pub pour
   voir s'il existe une version PostgreSQL plus récente ou des
   correctifs.
   
    1.14) Comment PostgreSQL se compare-til à d'autres SGBD ?
    
   Il y a plusieurs manières de mesurer un logiciel : les
   fonctionnalités, les performances, la fiabilité, le support, et le
   prix.
   
   Fonctionnalités
          PostgreSQL possède la plupart des fonctionnalités présentes
          dans les SGBD commerciaux, comme les transactions, les requêtes
          imbriquées, les déclencheurs, les vues, l'intégrité
          référentielle par clés étrangères, et le verrouillage
          sophistiqué. Nous avons des fonctionnalités qu'ils n'ont pas,
          comme les types définis par l'utilisateur, l'héritage, les
          règles, et le contrôle de concurrence par multi-versionnage
          pour réduire les contentions de verrouillage.
          
   Performances
          PostgreSQL a des performances similaires aux autres bases de
          données commerciales et open source. Il est plus rapide pour
          certaines opérations, plus lent pour d'autres. Par rapport à
          MySQL ou d'autres SGBD plus léger, nous sommes plus rapides
          pour de nombreux utilisateurs, des requêtes complexes et une
          charge pour les requêtes de lecture/écriture. MySQL est plus
          rapide pour des requêtes SELECT simples effectuées par quelques
          utilisateurs. Bien sûr, MySQL ne possède aucune des
          fonctionnalités de la section Fonctionnalités ci-dessus.
          PostgreSQL est construit pour la fiabilité et les
          fonctionnalités et nous continuons à améliorer les performances
          à chaque version. Il y a une page web intéressante qui compare
          PostgreSQL à MySQL sur
          http://openacs.org/philosophy/why-not-mysql.html. De plus,
          MySQL est une société qui distribue son produit via l'open
          source et requiert une licence commerciale pour les logiciels
          propriétaires, donc pas une communauté de développement open
          source comme PostgreSQL.
          
   Fiabilité
          Nous somme conscients qu'un SGBD doit être fiable ou bien il
          est inutile. Nous faisons le maximum pour sortir des versions
          bien testées, du code stable ne contenant qu'un minimum de
          bogues. Chaque version a au moins un mois de tests, et notre
          historique de versions montre que nous pouvons fournir des
          versions stables et robustes, prêtes pour une utilisation en
          environnement de production. Nous pensons que nous nous
          comparons favorablement aux autres bases de données dans ce
          domaine.
          
   Support
          Nos listes de diffusion offrent un contact avec un large groupe
          de développeurs et d'utilisateurs afin d'aider à la résolution
          des problèmes rencontrés. Nous ne pouvons garantir un correctif
          mais les SGBD commerciaux ne le garantissent pas toujours non
          plus. L'accès direct aux développeurs, à la communauté
          d'utilisateurs, aux manuels, et au code source, fait du support
          pour PostgreSQL un support supérieur aux autres SGBD. Un
          support commercial par incident est disponible pour ceux qui en
          ont le besoin (voir la section 1.6 de la FAQ).
          
   Prix
          Nous sommes gratuits pour tous les usages, commerciaux et non
          commerciaux. Vous pouvez inclure notre code dans vos produits
          sans limitation, exceptées celles citées dans notre licence de
          type BSD donnée plus haut.
          
    1.15) Comment puis-je aider financièrement PostgreSQL ?
    
   PostgreSQL possède une infrastructure de première classe depuis le
   début en 1996. Ceci grâce à Marc Fournier, qui a créé et géré cette
   infrastructure des années durant.
   
   Une infrastructure de qualité est importante pour un projet
   open-source. Cela permet d'empêcher l'éparpillement qui ralentirait
   beaucoup l'avancement du projet.
   
   Bien sûr, cette infrastructure n'est pas donnée. Elle requiert un
   certain nombre de dépenses mensuelles ou ponctuelles. Si vous ou votre
   société peut donner de l'argent pour soutenir cet effort, merci de
   consulter la page web http://store.pgsql.com/shopping/ et de faire une
   donation.
   
   Bien que la page web mentionne PostgreSQL, Inc, les contributions sont
   exclusivement utilisées pour soutenir le projet PostgreSQL et ne
   soutiennent aucune société que ce soit. Si vous le préférez, vous
   pouvez aussi envoyer un chèque à l'adresse de contact.
     _________________________________________________________________
   
   De plus, si vous avez une histoire de succès avec PostgreSQL, merci de
   la soumettre à notre site d'évangélisation sur
   http://advocacy.postgresql.org.
   
                    Questions sur le client utilisateur
                                      
    2.1) Existe-t'il des pilotes ODBC pour PostgreSQL ?
    
   Il y a deux pilotes ODBC disponibles, PsqlODBC et OpenLink ODBC.
   
   Vous pouvez télécharger PsqlOBDC depuis
   http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
   
   OpenLink ODBC peut être obtenu depuis http://www.openlinksw.com. Il
   fonctionne avec leur logiciel client ODBC standard, vous aurez donc
   PostgreSQL ODBC sur toutes les plateformes client qu'ils supportent
   (Win, Mac, Unix, VMS).
   
   Ils vendront probablement ce produit aux gens qui recherchent une
   qualité de support professionnelle mais une version freeware sera
   toujours disponible. Merci d'envoyer vos questions à
   postgres95@openlink.co.uk.
   
    2.2) Quels outils sont disponibles pour utiliser PostgreSQL avec des pages
    Web ?
    
   Une bonne introduction aux pages Web adossés à une base de données se
   trouve à http://www.webreview.com
   
   Pour l'intégration Web, PHP est une excellente interface. Elle se
   trouve à http://www.php.net.
   
   Pour les cas complexes, beaucoup utilisent l'interface Perl et CGI.pm
   ou mod_perl.
   
    2.3) PostgreSQL a-t-il une interface graphique ?
    
   Oui, il y a plusieurs interfaces graphiques disponibles pour
   PostgreSQL, dont PgAccess http://www.pgaccess.org), PgAdmin III
   (http://www.pgadmin.org), RHDB Admin (http://sources.redhat.com/rhdb/
   et Rekall ( http://www.thekompany.com/products/rekall/, propriétaire).
   Il y a aussi PhpPgAdmin ( http://phppgadmin.sourceforge.net/ ), une
   interface Web pour PostgreSQL.
   
   Voir http://techdocs.postgresql.org/guides/GUITools pour une liste
   plus détaillée.
   
    2.4) Quels langages sont disponibles pour communiquer avec PostgreSQL ?
    
   La plupart des langages de programmation couramment utilisés ont une
   interface pour PostgreSQL. Vérifiez la liste des modules de votre
   langage.
   
   Les interfaces ci-dessous sont incluses dans la distribution :
     * C (libpq)
     * Embedded C (ecpg)
     * Java (jdbc)
     * Python (PyGreSQL)
     * TCL (libpgtcl)
       
   Interfaces supplémentaires disponibles sur http://gborg.postgresql.org
   dans la section Drivers/Interfaces
     _________________________________________________________________
   
                         Questions Administratives
                                      
    3.1) Comment installer PostgreSQL ailleurs que sous /usr/local/pgsql ?
    
   Il faut spécifier l'option --prefix lors du lancement de configure.
   
    3.2) Quand je lance postmaster, j'obtiens un Bad System Call ou un message
    core dumped . Pourquoi ?
    
   Cela peut être dû à une variété de problèmes mais vérifiez d'abord que
   vous avez les extensions System V installées pour votre noyau.
   PostgreSQL nécessite le support noyau pour la mémoire partagée et les
   sémaphores.
   
    3.3) Quand je lance postmaster, j'obtiens des erreurs IpcMemoryCreate.
    Pourquoi ?
    
   Soit vous n'avez pas configuré correctement la mémoire partagée dans
   votre noyau, soit vous devez augmenter la mémoire partagée disponible
   dans le noyau. Le montant exact dont vous avez besoin dépend de votre
   architecture et du nombre de tampons et de processus que vous avez
   configuré pour postmaster. Pour la plupart des systèmes avec un nombre
   par défaut de tampons et de processus, vous aurez besoin d'un minimum
   d'environ 1 Mo. Voir le chapitre Administration du manuel PostgreSQL
   pour des informations plus détaillées sur la mémoire partagée et les
   sémaphores.
   
    3.4) Quand je lance postmaster, j'obtiens des erreurs IpcSemaphoreCreate.
    Pourquoi ?
    
   Si le message d'erreur est IpcSemaphoreCreate: semget failed (No space
   left on device) alors votre noyau n'est pas configuré avec
   suffisamment de sémaphores. PostgreSQL a besoin d'un sémaphore par
   processus serveur potentiel. Une solution provisoire est de lancer
   postmaster avec une plus petite limite sur le nombre de processus
   serveur. Utilisez l'option -N avec un paramètre inférieur au choix par
   défaut de 32. Une solution permanente est d'augmenter les paramètres
   SEMMNS et SEMMNI de votre noyau.
   
   Des sémaphores inopérantes peuvent aussi provoquer des plantages
   pendant de gros accès à la base de données.
   
   Si le message d'erreur est autre chose, vous n'avez peut-être pas du
   tout le support des sémaphores dans votre noyau. Voir le chapitre
   Administration du manuel PostgreSQL pour des informations plus
   détaillées sur la mémoire partagée et les sémaphores.
   
    3.5) Comment contrôler les connexions d'autres machines ?
    
   Par défaut, PostgreSQL n'autorise que les connexions de la machine
   locale utilisant les sockets de domaine Unix. D'autres machines ne
   seront pas capables de se connecter sauf si vous configurez
   tcpip_sockets dans postgresql.conf et activez l'authentification basée
   sur l'hôte en modifiant le fichier $PGDATA/pg_hba.conf en conséquence.
   Ceci autorisera les connexions TCP/IP.
   
    3.6) Comment régler le moteur de la base de données pour de meilleures
    performances ?
    
   Des index accéléreront les requêtes. La commande EXPLAIN ANALYZE vous
   permet de voir comment PostgreSQL traite votre requête et quels index
   sont utilisés.
   
   Si vous faites beaucoup d'insertions (instruction INSERT), envisagez
   de les faire en une fois en utilisant la commande COPY. Ceci est plus
   rapide que des commandes INSERTS individuelles. Deuxièment, les
   requêtes qui ne sont pas dans des blocs de transaction BEGIN
   WORK/COMMIT sont considérés comme étant dans leur propre transaction.
   Envisagez de faire plusieurs instructions dans un seul bloc de
   transaction. Ceci réduira la surcharge apportée par les transactions.
   Aussi, envisagez d'abandonner et de recréer des index lors de grosses
   modifications de données.
   
   Il y a plusieurs options d'optimisations. Vous pouvez désactiver
   fsync() en lançant postmaster avec l'option -o -F. Ceci empêchera les
   fsync()s d'écrire sur disque après toute transaction.
   
   Vous pouvez utiliser l'option -B de postmaster pour augmenter le
   nombre de tampons de mémoire partagée utilisés par les processus
   serveurs. Si vous fixez ce paramètre trop haut, postmaster ne se
   lancera pas car vous avez dépassé la limite de votre noyau sur la
   quantité de mémoire partagée. Chaque tampon fait 8 Ko et le choix par
   défaut est de 64 tampons.
   
   Vous pouvez utiliser l'option serveur -S pour augmenter la quantité
   maximale de mémoire utilisée par les processus serveurs pour des tris
   temporaires. La valeur de -S est mesuré en kilooctets et le choix par
   défaut est de 512 (c'est-à-dire 512 Ko).
   
   Vous pouvez utiliser la commande CLUSTER pour regrouper vos données en
   tables pour correspondre à un index. Voir la page de manual CLUSTER
   pour plus de détails.
   
    3.7) Quelles fonctionalités de déboguage sont disponibles ?
    
   PostgreSQL a plusieurs fonctionalités qui permettent de recueillir des
   informations de statut qui peuvent être utile pour des intentions de
   déboguage.
   
   D'abord, en lançant configure avec l'option --enable-cassert, beaucoup
   d'assert()s surveillent le serveur et arrêtent le programme quand
   quelque chose d'inattendu arrive.
   
   Postmaster et postgres ont tous deux plusieurs options de déboguage de
   disponible. D'abord, quand vous lancez postmaster, vérifiez que vous
   envoyez les sorties standard et d'erreur dans un fichier de traces
   comme :
    cd /usr/local/pgsql
    ./bin/postmaster >server.log 2>&1 &

   Ceci va créer un fichier server.log dans le répertoire racine de
   PostgreSQL. Ce fichier contient des informations utiles sur les
   problèmes ou erreurs rencontrés par le serveur. Postmaster dispose
   d'une option -d qui permet de rapporter des informations encore plus
   détaillées d'être rapportées. L'option -d prend un numéro qui spécifie
   le niveau de déboguage. Faites attention au fait que des valeurs
   élévées de niveau de déboguage génerent des fichiers de traces
   volumineux.
   
   Si postmaster ne tourne pas, vous pouvez lancer le serveur postgres de
   la ligne de commande et taper votre requête SQL directement. Ceci est
   recommandé seulement pour des fonctions de déboguage. Notez qu'un
   retour chariot termine la requête, pas un point-virgule. Si vous
   compilez avec les symboles de déboguage, vous pouvez utiliser un
   débogueur pour voir ce qui se passe. Parce que le serveur n'a pas été
   lancé par postmaster, il ne tourne pas dans un environnement identique
   et les problèmes d'interaction de verrouillage/serveur ne peuvent être
   dupliqués.
   
   Si postmaster est en train de tourner, lancez psql dans une fenêtre
   puis trouvez le PID du processus postgres utilisé par psql. Utilisez
   un débogueur pour l'attacher au PID postgres. Vous pouvez mettre un
   point d'arrêt dans le débogueur et envoyez des requêtes de psql. Si
   vous déboguez le démarrage de postgres, vous pouvez mettre
   PGOPTIONS="-W n", puis lancez psql. Ceci va retarder le démarrage de n
   secondes pour que vous puissiez attacher un débogueur au processus,
   fixer des points d'arrêt et continuer la séquence de démarrage.
   
   Le programme postgres a les options -s, -A et -t qui peuvent être
   utile pour des mesures de déboguage et de performance.
   
   Vous pouvez compiler avec les options de performance pour voir quelles
   fonctions prennent du temps d'exécution. Les fichiers de gestion du
   serveur seront déposés dans le répertoire pgsql/data/base/nom_db. Les
   fichiers de gestion clients seront mis dans le répertoire actuel du
   client. Linux requiert une compilation avec -DLINUX_PROFILE pour une
   meilleure gestion.
   
    3.8) Pourquoi est-ce que j'obtiens des messages Sorry, too many clients
    quand je me connecte ?
    
   Vous pouvez augmenter la limite de postmaster sur le nombre de
   processus serveur concurrents qu'il peut lancer.
   
   La limite par défaut est de 32 processus. Vous pouvez l'augmenter en
   relançant postmaster avec une valeur -N appropriée ou en modifiant
   postgresql.conf.
   
   Tenez compte du fait que si vous fixez -N plus grand que 32, vous
   devez aussi augmenter -B au-dela de sa valeur par défaut 64 ; -B doit
   valoir au moins deux fois -N et probablement plus pour une meilleure
   performance. Pour de grand nombres de processus serveurs vous aurez
   probablement aussi augmenter plusieurs parametres de configuration du
   noyau Unix. Les choses a vérifier incluent la taille maximale des
   blocs de mémoire partagée, SHMMAX ; le nombre maximal de sémaphores,
   SEMMNS et SEMMNI ; le nombre maximal de processus, NPROC ; le nombre
   maximal de processus par utilisateur, MAXUPRC ; et le nombre maximal
   de fichiers ouverts, NFILE et NINODE. La raison pour laquelle
   PostgreSQL a une limite sur le nombre de processus serveurs autorisés
   est pour que votre système ne tombe pas à court de ressources.
   
    3.9) Que contient le répertoire pgsql_tmp ?
    
   Ce répertoire contient des fichiers temporaires générés par le moteur
   de requête. Par exemple, si un tri doit être fait pour satisfaire un
   ORDER BY et que ce tri requiert plus de place que le paramètre -S du
   serveur n'autorise, alors des fichiers temporaires seront créés pour
   contenir les données nécessaires.
   
   Les fichiers temporaires sont d'habitude effacés automatiquement mais
   peuvent rester si un serveur s'arrête brutalement pendant un tri. Un
   arrêt et un redémarrage de postmaster effacera les fichiers dans ces
   répertoires.
   
    3.10) Pourquoi est-ce que j'ai besoin de faire une sauvegarde des bases et
    de restaurer pour mettre a jour les versions de PostgreSQL ?
    
   L'équipe PostgreSQL ne fait que des changements mineurs entre des
   versions mineurs, donc mettre à jour de 7.2 vers 7.2.1 ne nécessitera
   pas de sauvegarde et de restauration. Par contre, les sorties majeures
   (c'est-à-dire de 7.2 vers 7.3) changent souvent le format interne des
   tables systèmes et des fichiers de données. Ces modifications sont
   souvent complexes alors nous ne gardons pas de compatibilité
   descendante pour les fichiers de données. Une sauvegarde exportera les
   données dans un format générique qui peut ensuite être chargé dans le
   nouveau format interne.
   
   Dans les sorties où le format sur disque ne change pas, le script
   pg_upgrade peut être utilisé pour mettre à jour sans
   sauvegarde/restauration. Les notes de sorties précisent si pg_upgrade
   est disponible pour la sortie.
   
    3.11) Quels matériels dois-je utiliser ?
    
   Comme le matériel PC est compatible en grosse partie, les gens ont
   tendance à croire que tous les matériels PC sont de même qualité. Ce
   n'est pas le cas. La RAM ECC, le SCSI et les cartes-mère de qualité
   sont plus fiables et ont de meilleurs performances qu'un matériel
   moins coûteux. PostgreSQL fonctionnera sur à peu près tout matériel
   mais si la fiabilité et la performance sont importantes pour vous, il
   est rusé de bien considérer les options matérielles. Nos listes de
   diffusion peuvent être utilisées pour discuter des options matériels.
     _________________________________________________________________
   
                          Questions fonctionnelles
                                      
    4.1) Quelle est la différence entre curseur binaire et curseur normal ?
    
   Voir la page DECLARE du manuel pour une description.
   
    4.2) Comment faire un SELECT seulement sur les premières lignes d'une
    requête ? Sur une ligne aléatoire ?
    
   Voir la page FETCH du manuel ou utiliser SELECT ... LIMIT....
   
   Il se peut que l'intégralité de la requête doive être évaluée, même si
   vous voulez seulement les premières lignes. Envisagez d'utiliser une
   requête avec une clause ORDER BY. S'il existe un index correspondant à
   l'ORDER BY, PostgreSQL peut n'évaluer que les premières lignes, sinon
   l'intégralité de la requête peut être évaluée, jusqu'à générer les
   lignes désirées.
   
   Pour faire un SELECT sur une ligne aléatoire :
    SELECT colonne
    FROM table
    ORDER BY random()
    LIMIT 1;

    4.3) Comment obtenir une liste des tables ou d'autres objets que je vois
    dans psql ?
    
   Utilisez la commande \dt pour voir les tables dans psql. Pour une
   liste complète de commandes à l'intérieur de psql, vous pouvez
   utiliser \?. Autrement, vous pouvez lire le code source de psql dans
   le fichier pgsql/src/bin/psql/describe.c. Il contient des commandes
   SQL qui génèrent le contenu des commandes anti-slash de psql. Vous
   pouvez aussi lancer psql avec l'option -E, afin qu'il imprime les
   requêtes qu'il utilise pour exécuter les commandes que vous lui
   passez. PostgreSQL fournit aussi une interface d'informations sur le
   schéma compatible avec SQLi que vous pouvez interroger des
   informations sur la base de données.
   
    4.4) Comment supprime-t-on une colonne d'une table, ou comment change-t-on
    son type de données ?
    
   La fonction DROP COLUMN a été ajoutée dans la version 7.3 avec ALTER
   TABLE DROP COLUMN. Pour les versions précédentes, vous pouvez faire :
    BEGIN;
    LOCK TABLE ancienne_table;
    SELECT ...  -- sélectionnez toutes les colonnes sauf celle à supprimer
    INTO TABLE nouvelle_table
    FROM ancienne_table;
    DROP TABLE ancienne_table;
    ALTER TABLE nouvelle_table RENAME TO ancienne_table;
    COMMIT;

   Pour changer le type de données d'une colonne, faites :
    BEGIN;
    ALTER TABLE table ADD COLUMN nouvelle_colonne nouveau_type_de_donnees;
    UPDATE table SET nouvelle_colonne = CAST(ancienne_colonne AS nouveau_type_d
e_donnees);
    ALTER TABLE table DROP COLUMN ancienne_colonne;
    COMMIT;

   Après, vous pouvez faire VACUUM FULL tab pour récupérer l'espace
   disque utilisé par les lignes expirées.
   
    4.5) Quelle est la taille maximale pour une ligne, une table, une base de
    données ?
    
   Les limites sont :
    Taille maximum pour une base de données     illimitée (il existe des bases
de 32 To)
    Taille maximum pour une table               32 To
    Taille maximum pour une ligne               1,6 To
    Taille maximum pour un champ                1 Go
    Nombre maximum de lignes dans une table     illimité
    Nombre maximum de colonnes dans une table   250-1600, selon le type de colo
nnes
    Nombre maximum d'index sur une table        illimité

   Bien sûr, ces valeurs ne sont pas vraiment illimitée, elles sont
   limitées par l'espace disque disponible, ainsi que par l'espace de
   mémoire et de swap. Les performances peuvent se dégrader si ces
   valeurs sont inhabituellement grandes.
   
   La taille maximum des tables (32 To) ne nécessite pas que le système
   d'exploitation supporte les grands fichiers. Les grandes tables sont
   stockées sous forme de fichiers multiples de 1 Go, donc les limites de
   taille du système de fichier ne sont pas importantes.
   
   La taille maximum des tables et le nombre maximum de colonnes peuvent
   être quadriplés, si la taille des blocs par défaut est augmentée à
   32 Ko.
   
    4.6) Combien d'espace disque faut-il pour stocker les données d'un fichier
    texte typique ?
    
   Une base de données PostgreSQL peut utiliser jusqu'à cinq fois
   l'espace nécessaire pour stocker les données d'un fichier texte.
   
   A titre d'exemple, considérez un fichier de 100 000 lignes, comportant
   un entier et une chaîne de description sur chaque ligne. Supposons que
   la chaîne soit longue en moyenne de 20 octets. Le fichier texte serait
   de 2,8 Mo. La taille du fichier d'une base de données PostgreSQL peut
   être estimée à 6,4 Mo :
    36 octets: chaque ligne (approximation)
    24 octets: un champ 'entier' et un champ 'texte'
   + 4 octets: pointeur vers le tuple sur la page
   ----------------------------------------
    64 octets par ligne

   La taille des pages de données dans PostgreSQL est de 8192 octets (8 KO), do
nc :

   8192 octets par page
   ----------------------   = 128 lignes par page de base de données (arrondi à
 l'entier inférieur)
     64 octets par ligne

   100000 lignes de données
   -------------------------  =  782 pages de base de données (arrondi à l'enti
er supérieur)
      128 lignes par page

782 pages de base de données * 8192 octets par page  =  6 406 144 octets (6,4 M
o)

   Les index utilisent moins d'espace, mais ils contiennent les données
   indexées, ils peuvent donc également être grands.
   
   Les NULL sont stockés sous forme de bitmap, aussi utilisent-ils très
   peu d'espace.
   
    4.7) Comment puis-je savoir quels index, tables, bases de données et
    utilisateurs sont définis ?
    
   psql dispose de plusieurs commandes commençant par un anti-slash pour
   retrouver ces informations. Utilisez \? pour les connaître. Il existe
   aussi des tables systèmes, qui commencent par pg_ et qui les décrivent
   également. Aussi, psql -l liste toutes les bases de données.
   
   Essayez également le fichier pgsql/src/tutorial/syscat.source. Il
   illustre un grand nombre de commandes SELECT nécessaires pour
   récupérer l'information des tables système de la base de données.
   
    4.8) Mes requêtes sont lentes ou ne font pas usage des index. Pourquoi ?
    
   Les index ne sont pas automatiquement utilisés par chaque requête. Ils
   sont utilisés uniquement si la table est plus grande qu'une certaine
   taille, et si la requête sélectionne seulement un faible pourcentage
   des lignes de la table. Ceci est dû au fait qu'un accès disque
   aléatoire causé par un parcours d'index peut être plus lent qu'une
   simple lecture de la table, ou parcours séquentiel
   
   Pour déterminer si un index devrait être utilisé, PostgreSQL a besoin
   des statistiques de la table. Ces statistiques sont collectées en
   lançant VACUUM ANALYZE ou simplement ANALYZE. Avec les statistiques,
   l'optimiseur sait combien de lignes se trouvent dans la table et peut
   mieux déterminer s'il faut utiliser l'index. Les statistiques sont
   également utiles pour déterminer l'ordre optimal des opérations de
   jointure. La collecte des statistiques devrait être effectuée
   régulièrement lorsque le contenu de la table change.
   
   Les index ne sont normalement pas utilisés pour les clauses ORDER BY
   ou pour les jointures. Un parcours séquentiel suivi d'un tri explicite
   est habituellement plus rapide qu'un parcours d'index pour une table
   importante. Toutefois, LIMIT combiné avec ORDER BY utilisera souvent
   un index parce que seulement une petite partie de la table est
   renvoyée. En fait, bien que MAX() et MIN() n'utilisent pas les index,
   il est possible de retrouver ces valeurs en utilisant un index avec
   ORDER BY et LIMIT :
    SELECT colonne
    FROM table
    ORDER BY colonne [ DESC ]
    LIMIT 1;

   Si vous pensez que l'optimiseur choisit par erreur un parcours
   sequentiel, utilisez SET enable_seqscan TO 'off' et lancez des tests
   pour voir si le parcours d'index est effectivement plus rapide.
   
   Lorsque vous utilisez des caractères joker tels que LIKE ou ~, les
   index peuvent seulement être utilisés dans certaines circonstances :
     * Le début de la chaîne de recherche doit être ancré au départ de la
       chaîne, c'est-à-dire
          + Les modèles pour LIKE ne doivent pas commencer par %.
          + Les modèles d'expression régulière pour ~ doivent commencer
            par ^.
     * La chaîne de recherche ne peut pas commencer par une classe de
       caractères, c'est-à-dire [a-e].
     * Les recherches sans casse comme ILIKE et ~* n'utilisent pas les
       index. Utilisez plutôt les index fonctionnels, décrit dans la
       section 4.12.
     * La locale C par défaut doit être utilisée lors de initdb.
       
    4.9) Comment puis-je savoir si l'optimiseur évalue mes requêtes ?
    
   Voir la page EXPLAIN du manuel.
   
    4.10) Qu'est-ce qu'un index R-tree ?
    
   Un index R-tree est utilisé pour l'indexation des données spatiales.
   Un index de hachage ne permet pas les recherches par plage. Un index
   B-tree peut seulement faire des recherches sur une dimension. Les
   index R-tree peuvent traiter des données multi-dimensionnelles. Par
   exemple, si un index R-tree peut être construit sur un attribut de
   type point, le système peut plus efficacement gérer les requêtes du
   type "Sélection de tous les points d'un rectangle".
   
   L'article de référence qui décrit le système R-tree original est :
   
   Guttman, A. "R-trees: A Dynamic Index Structure for Spatial
   Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of
   Data, 45-57.
   
   Vous pouvez également trouver ce papier dans le livre de Stonebraker
   "Readings in Database Systems".
   
   Les index R-tree intégrés peuvent prendre en charge les polygônes et
   les boîtes. En théorie, les R-trees peuvent être étendus à un plus
   grand nombre de dimensions. En pratique, l'extension des R-trees
   requiert pas mal de travail et nous n'avons pour le moment aucune
   documentation sur la façon de procéder.
   
    4.11) Qu'est-ce que l'optimiseur génétique de requêtes ?
    
   Le module GEQO (acronyme de GEnetic Query Optimizer) accélère
   l'optimisation des requêtes lors de jointures de nombreuses tables par
   un algorithme génétique (GA). Il permet la gestion des grosses
   requêtes de jointures en utilisant une recherche non exhaustive.
   
    4.12) Comment puis-je réaliser des recherches sur des expressions
    rationnelles ainsi que des recherches non sensibles à la casse ? Comment
    puis-je utiliser un index lors de recherches non sensibles à la casse ?
    
   L'opérateur ~ réalise des recherches d'expressions rationnelles et ~*
   le fait sans tenir compte de la casse. La variante de LIKE non
   sensible à la casse est ILIKE.
   
   Des comparaisons d'égalité non sensibles à la casse sont
   habituellement exprimées de cette façon :
    SELECT *
    FROM table
    WHERE lower(colonne) = 'abc';

   Ceci n'utilisera pas un index standard. Néanmoins, si vous créez un
   index fonctionnel, celui-ci sera utilisé :
    CREATE INDEX tableindex ON table (lower(colonne));

    4.13) Comment puis-je détecter si un champ est NULL dans une requête ?
    
   Il vous suffit de tester la colonne avec IS NULL ou IS NOT NULL.
   
    4.14) Quelle sont les différences entre les nombreux types de caractères ?
    
Type            Nom interne     Notes
--------------------------------------------------
VARCHAR(n)      varchar         n spécifie la taille maximum, sans remplissage
CHAR(n)         bpchar          des espaces sont ajoutés pour obtenir la
                                longueur fixe spécifiée
TEXT            text            pas de limite supérieure pour la taille
BYTEA           bytea           tableau d'octets (accepte les octets nuls)
"char"          char            un caractère

   Vous verrez le nom interne en examinant les catalogues système et dans
   quelques messages d'erreur.
   
   Les quatres premiers types du dessus sont des types "varlena"
   (c'est-à-dire que les quatre premiers octets correspondent à la
   taille, suivi des données). Donc, l'espace réellement utilisé est
   légèrement plus grand que la taille déclarée. Néanmoins, ces types de
   données sont aussi sujet à la compression ou à un enregistrement en
   dehors de la table avec TOAST, donc l'espace occupé sur disque
   pourrait aussi être moindre que ce qu'on pourrait attendre.
   
   VARCHAR(n) est bien mieux pour enregistrer des chaînes de longueurs
   variables tout en limitant la taille de cette chaîne. TEXT est utile
   pour les chaînes de longueur illimitée, avec malgré tout un maximum de
   1 Go.
   
   CHAR(n) est intéressant pour stocker des chaînes de taille identique.
   CHAR(n) complète avec des espaces pour arriver à la taille spécifiée
   alors que VARCHAR(n) n'enregistre que les caractères donnés. BYTEA
   sert à stocker des données binaires, particulièrement les données
   incluant des octets NULL. Tous les types décrits ici ont des
   performances similaires.
   
    4.15.1) Comment puis-je créer un champ série, c'est-à-dire s'incrémentant
    automatiquement ?
    
   PostgreSQL supporte un type de données SERIAL. Il crée automatiquement
   une séquence. Par exemple, ceci :
    CREATE TABLE personne (
        id  SERIAL,
        nom TEXT
    );

   est automatiquement traduit en ceci :
    CREATE SEQUENCE personne_id_seq;
    CREATE TABLE personne (
        id  INT4 NOT NULL DEFAULT nextval('personne_id_seq'),
        nom TEXT
    );

   Voir la page man de create_sequence pour plus d'informations sur les
   séquences. Vous pouvez aussi utiliser le champ OID de chaque ligne
   comme valeur unique. Néanmoins, si vous avez besoin de sauvegarder
   puis recharger la base de données, vous devrez utiliser l'option -o ou
   l'option COPY WITH OIDS de pg_dump pour conserver les OIDs.
   
    4.15.2) Comment puis-je obtenir la valeur d'un SERIAL suite à une
    insertion ?
    
   Une approche pour récupérer la prochaine valeur SERIAL à partir de
   l'objet séquence est d'utiliser la fonction nextval() avant
   l'insertion et de l'insérer ensuite explicitement. En utilisant la
   table d'exemple de la section 4.15.1, un exemple dans un
   pseudo-langage ressemblerait à ceci :
    nouvelle_id = execute("SELECT nextval('personne_id_seq')");
    execute("INSERT INTO personne (id, nom) VALUES (nouvelle_id, 'Blaise Pascal
')");

   Vous pourriez ensuite utiliser la nouvelle valeur stockée dans
   nouvelle_id avec d'autres requêtes (c'est-à-dire en tant que clé
   étrangère de la table personne). Notez que le nom de la SEQUENCE
   automatiquement créée sera <table>_<colonneserial>_seq, où table et
   colonneserial sont les noms respectifs de votre table et de votre
   colonne SERIAL.
   
   Autrement, vous pouvez récupérer la valeur SERIAL affectée avec la
   fonction currval() après qu'elle ait été insérée par défaut,
   c'est-à-dire,
    execute("INSERT INTO personne (nom) VALUES ('Blaise Pascal')");
    nouvelle_id = execute("SELECT currval('personne_id_seq')");

   Enfin, vous pouvez utiliser l'OID renvoyé par l'instruction INSERT
   pour récupérer la valeur par défaut bien que cela soit l'appoche la
   moins portable et la valeur de l'OID se réinitialisera aux environs de
   quatre milliards. En Perl, avec DBI et le module DBD:Pg d'Edmund
   Mergl, l'ancienne valeur est disponible via $sth->{pg_oid_status}
   après un $sth->execute().
   
    4.15.3) Est-ce que currval() et nextval() n'amènent pas des problèmes
    lorsque plusieurs utilisateurs les lancent en même temps ?
    
   Non. currval() renvoie la valeur actuelle affectée par votre
   processus, et non pas par tous les utilisateurs.
   
    4.15.4) Pourquoi mes numéros de séquences ne sont pas ré-utilisés lors
    d'une annulation de transaction ? Pourquoi existe-t'il des trous dans la
    numérotation de ma colonne séquentielle (SERIAL) ?
    
   Pour améliorer les accès concurrents, les valeurs de séquences sont
   données aux transactions qui en ont besoin et ne sont pas bloquées
   jusqu'à la fin de la transaction. Ceci crée des trous dans le
   numérotage pour les transactions annulées.
   
    4.16) Qu'est-ce qu'un OID ? Qu'est-ce qu'un TID ?
    
   Les OID sont la réponse de PostgreSQL aux identifiants de lignes
   uniques. Chaque ligne créée dans PostgreSQL obtient un OID unique.
   Tous les OID générés pendant initdb sont inférieurs à 16384 (voir
   include/access/transam.h). Tous les OID créés par un utilisateur sont
   supérieurs ou égaux à ceci. Par défaut, tous ces OID sont uniques non
   seulement dans une table ou une base mais unique à l'intérieur d'une
   installation PostgreSQL entière.
   
   PostgreSQL utilise les OID dans ses tables système interne pour lier
   les lignes entre tables. Ces OID peuvent être utilisés pour identifier
   des lignes utilisateurs spécifiques et utilisés dans des jointures. Il
   est recommandé que vous utilisiez le type de colonne OID pour stocker
   des valeurs OID. Vous pouvez créer un index sur le champ OID pour un
   accès plus rapide.
   
   Les OID sont attribués pour toute ligne d'un endroit central qui est
   utilisé par toutes les bases de données. Si vous voulez changer l'OID
   en quelque chose d'autre ou si vous voulez faire une copie de la table
   avec les OID originaux, il n'y a pas de raisons pour ne pas le faire :
    CREATE TABLE nouvelle_table (macolonne int);
    SELECT oid AS ancienne_oid, macolonne INTO table_temporaire FROM ancienne_t
able;
    COPY table_temporaire FROM '/tmp/tablepg';
    COPY nouvelle_table WITH OIDS FROM '/tmp/tablepg';
    DROP TABLE table_temporaire;

   Les OID sont stockés en tant qu'entiers de quatre octets et
   déborderont à quatre milliards. Personne n'a jamais rapporté un tel
   cas et nous avons prévu de retirer la limite avant que cela ne se
   produise.
   
   Les TIDs sont utilisés pour identifier des lignes physiques
   spécifiques avec des valeurs de bloc et décalage. Les TID changent
   après que les lignes aient été modifiés ou rechargés. Ils sont
   utilisés par des entrées d'index pour pointer vers des lignes
   physiques.
   
    4.17) A quoi correspond certains termes utilisés avec PostgreSQL ?
    
   Une partie du code source et de l'ancienne documentation utilisent des
   termes dont l'usage est plus commun. Voici quelques exemples :
     * table, relation, classe
     * ligne (row), enregistrement (record), tuple
     * colonne (column), champ (field), attribut
     * récupère, sélectionne (select)
     * remplace (replace), met à jour (update)
     * ajoute (append), insère (insert)
     * OID, valeur séquentielle (serial value)
     * portal, curseur
     * range variable, table name, table alias
       
   Une liste des termes généraux pour le domaine des bases de données est
   disponible sur :
   http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
   /glossary.html
   
    4.18) Pourquoi ai-je l'erreur ERROR: Memory exhausted in AllocSetAlloc() ?
    
   Vous manquez probablement de mémoire virtuelle sur votre système ou
   votre noyau a une limite assez basse pour certaines ressources.
   Essayez ceci avant de lancer postmaster :
    ulimit -d 262144
    limit datasize 256m

   Suivant votre shell, seul un d'eux pourrait réussir mais cela
   configurera d'une façon plus importante la taille du segment de
   données de votre processus. Cette commande s'applique au processus
   actuel et à tous les processus lancé par celui-ci. Si vous avez des
   problèmes avec le client SQL parce que le processus serveur renvoie
   trop de données, essayez ça avant de lancer le client.
   
    4.19) Comment puis-je connaître la version de PostgreSQL que j'utilise ?
    
   A partir de psql, tapez SELECT version();
   
    4.20) Pourquoi ai-je invalid large obj descriptor lors d'opérations sur des
    gros objects ?
    
   Vous avez besoin de placer BEGIN WORK et COMMIT autour de chaque
   utilisateur de gros objets, c'est-à-dire pour entourer lo_open ...
   lo_close.
   
   Actuellement, PostgreSQL force cette règle en fermant les gros objets
   lors de la transaction. Donc, le premier essai d'opérations sur ces
   objets, fonctionnant habituellement (au moins la plupart du temps)
   aura un invalid large obj descriptor. Donc le code, auparavant
   fonctionnel (au moins la plupart du temps), génèrera maintenant un
   message d'erreur si vous n'utilisez pas de transaction.
   
   Si vous utilisez une interface client interface comme ODBC, vous aurez
   peut-être besoin de lancer auto-commit off.
   
    4.21) Comment puis-je créer une colonne qui aura par défaut l'heure
    actuelle comme valeur ?
    
   Utilisez CURRENT_TIMESTAMP:
CREATE TABLE test (x int, heuremodif timestamp DEFAULT CURRENT_TIMESTAMP );

    4.22) Pourquoi mes sous-requêtes utilisant IN sont-elles si lentes ?
    
   Dans les versions précédant la 7.4, les sous-requêtes ont été jointes
   avec des jointures externes en parcourant séquentiellement le résultat
   de la sous-requête pour chaque ligne de la requête externe. Si la
   sous-requête renvoit quelques lignes et que la requête externe en
   renvoit plein, IN sera plus rapide. Pour accélérer les autres
   requêtes, remplacez IN avec EXISTS :
    SELECT *
    FROM table
    WHERE colonne IN (SELECT souscolonne FROM soustable);

   to:
    SELECT *
    FROM table
    WHERE EXISTS (SELECT souscolonne FROM soustable WHERE souscolonne = colonne
);

   Pour que ceci soit rapide, souscolonne doit être une colonne indexée.
   
   A partir de la version 7.4, IN utilise actuellement les mêmes
   techniques sophistiquées de jointures comme des requêtes normales et
   est préféré à l'utilisation de EXISTS.
   
    4.23) Comment puis-je réaliser une jointure externe ?
    
   PostgreSQL supporte les jointures externes en utilisant la syntaxe SQL
   standard. Voici deux exemples :
    SELECT *
    FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

   or
    SELECT *
    FROM t1 LEFT OUTER JOIN t2 USING (col);

   Ces requêtes identiques joignent t1.col à t2.col et renvoient toute
   colonne non jointe de t1 (celles sans correspondance dans t2). Une
   jointure droite (RIGHT join) ajoutera les lignes non jointes de t2.
   Une jointure complète (FULL join) renverra les lignes correspondantes
   ainsi que les lignes non jointes de t1 et t2. Le mot clé OUTER est
   optionnelle et assumé dans le cas de jointure LEFT, RIGHT et FULL. Les
   jointures ordinaires sont appelées des jointures INNER.
   
   Lors des précédentes versions, les jointures externes peuvent être
   simulées en utilisant UNION et NOT IN. Par exemple, lors d'une
   jointure de tab1 et tab2, la requête suivante réalise une jointure
   externe, outer, des deux tables :
    SELECT tab1.col1, tab2.col2
    FROM tab1, tab2
    WHERE tab1.col1 = tab2.col1
    UNION ALL
    SELECT tab1.col1, NULL
    FROM tab1
    WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
    ORDER BY col1

    4.24) Comment puis-je lancer des requêtes utilisant plusieurs bases de
    données ?
    
   Il n'existe pas de moyens de lancer des requêtes sur une autre base
   que la courante. Comme PostgreSQL charge des catalogues systèmes
   spécifiques à la base de données, sa réaction aux requêtes inter-base
   de données est incertaine.
   
   contrib/dblink permet les requêtes entre bases de données en utilisant
   des fonctions. Bien sûr un client peut réaliser des connexions
   simultanées à plusieurs bases de données et joindre les résultats du
   côté client.
   
    4.25) Comment puis-je renvoyer plusieurs lignes ou colonnes à partir d'une
    fonction?
    
   A partir de la 7.3, vous pouvez facilement renvoyer plusieurs lignes
   ou colonnes à partir d'une fonction,
   http://techdocs.postgresql.org/guides/SetReturningFunctions.
   
    4.26) Pourquoi ne puis-je pas créer/supprimer des tables temporaires dans
    les fonctions PL/PgSQL de façon stable ?
    
   PL/PgSQL cache le contenu des fonctions et un effet de bord malheureux
   est que si une fonction PL/PgSQL accède à une table temporaire, que
   cette table est ensuite supprimée et recréée, et que la fonction est
   appelée de nouveau, la fonction échouera car le contenu de la fonction
   cachée pointera toujours vers l'ancienne table temporaire. La solution
   revient à utiliser EXECUTE pour l'accès aux tables temporaires avec
   PL/PgSQL. Ceci obligera l'analyse de la requête à chaque fois.
   
    4.27) Quelles options de réplication sont disponibles ?
    
   Il existe plusieurs solutions de réplication maître/esclave. Elles
   permettent uniquement au maître de réaliser des changements sur la
   base de données alors que l'esclave peut seulement faire des lectures
   de base de données. Le bas de la page
   http://gborg.PostgreSQL.org/genpage?replication_research les liste.
   Une solution de réplication multi-maître est en cours de développement
   sur http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
   
    4.28) Quelles options de cryptage sont disponibles ?
    
     * contrib/pgcrypto contient de nombreuses fonctions de cryptage, à
       utiliser dans des requêtes SQL.
     * Pour crypter une transmission entre le client et le serveur, le
       serveur doit avoir positionné l'option ssl à true dans
       postgresql.conf, et un enregistrement applicable host ou hostssl
       doit exister dans pg_hba.conf, et le sslmode du client ne doit pas
       être désactivée. Notez qu'il est aussi possible d'utiliser un
       transport crypté d'une troisième partie, tel que stunnel ou ssh,
       plutôt que les connexions SSL natives de PostgreSQL.
     * Les mots de passe des utilisateurs sont automatiquement cryptés
       depuis la version 7.3. Pour les versions précédentes, vous devez
       activer l'option PASSWORD_ENCRYPTION dans postgresql.conf.
     * Le serveur peut fonctionner avec un système de fichiers cryptés.
     _________________________________________________________________
   
                             Etendre PostgreSQL
                                      
    5.1) J'ai écrit une fonction utilisateur. Lorsque je l'exécute avec psql,
    pourquoi cela finit-il avec un dump core ?
    
   Il peut y avoir plusieurs raisons. Essayez tout d'abord votre fonction
   utilisateur dans un programme de test.
   
    5.2) Comment puis-je ajouter de bons nouveaux types ou fonctions à
    PostgreSQL ?
    
   Envoyez vos extensions à la liste de diffusion pgsql-hackers, elles
   atterriront éventuellement dans le sous-répertoire contrib/.
   
    5.3) Comment faire pour écrire une fonction C qui renvoie un tuple ?
    
   Dans les versions de PostgreSQL à partir de 7.3, les fonctions qui
   renvoient une table sont totalement supportées en C, PL/PgSQL, et SQL.
   Voir le Guide du Programmeur pour plus d'information. Un exemple de
   fonction renvoyant une table définie en C se trouve à
   contrib/tablefunc.
   
    5.4) J'ai modifié un fichier source. Pourquoi ma recompilation ne voit-elle
    pas les modifications ?
    
   Les Makefiles n'ont pas les dépendances adéquates pour les fichiers
   d'en-tête. Il vous faut faire make clean puis un autre make. Si vous
   utilisez GCC, vous pouvez utiliser l'option --enable-depend de
   configure pour que le compilateur calcule les dépendances
   automatiquement.
