Mise à jour en version 9.0.16

postgresql/config.xml

@@ -4655,13 +4655,15 @@ COPY postgres_log FROM '/chemin/complet/vers/le/logfile.csv' WITH csv;
         <primary>paramètre de configuration <varname>check_function_bodies</varname></primary>
       </indexterm>
         <para>
-          Ce paramètre est habituellement positionné à
-	  <literal>on</literal>. Positionné à <literal>off</literal>, il
-	  désactive la validation du corps de la fonction lors de
-	  <xref linkend="sql-createfunction"/>.
-	  Désactiver la validation est parfois utile. Cela permet, par
-	  exemple, d'éviter des problèmes de références lors de la restauration
-	  de définitions de fonctions à partir d'une sauvegarde.
+          Ce paramètre est habituellement positionné à <literal>on</literal>.
+          Positionné à <literal>off</literal>, il désactive la validation du
+          corps de la fonction lors de <xref linkend="sql-createfunction"
+          endterm="sql-createfunction-title"/>. Désactiver la validation évite
+          les effets de bord du processus de validation et évite les faux
+          positifs dûs aux problèmes, par exemple les références. Configurer
+          ce paramètre à <literal>off</literal> avant de charger les fonctions
+          à la place des autres utilisateurs&nbsp;;
+          <application>pg_dump</application> le fait automatiquement.
         </para>
       </listitem>
     </varlistentry>

postgresql/docguide.xml

@@ -919,25 +919,20 @@ save_size.pdfjadetex = 15000
    <title>Fichiers texte</title>
 
    <para>
-    Plusieurs fichiers sont distribués comme fichiers texte pour être lus lors
-    de la phase d'installation. Le fichier <filename>INSTALL</filename>
-    correspond au <xref linkend="installation"/>, avec quelques changements
-    mineurs pour tenir compte de contextes différents. Pour recréer le
-    fichier, se placer dans le répertoire <filename>doc/src/sgml</filename> et
-    entrer la commande <userinput>gmake INSTALL</userinput>. Ceci crée
-    un fichier <filename>INSTALL.html</filename> qui peut être enregistré au
-    format texte avec <productname>Netscape Navigator</productname> pour remplacer
-    le fichier existant. <productname>Netscape</productname> semble fournir la
-    meilleure qualité pour la conversion du <acronym>HTML</acronym> en texte
-    (comparé à <application>lynx</application> et à
-    <application>w3m</application>).
+    Les instructions d'installation sont aussi distribuées sous la forme d'un
+    fichier texte, au cas où cela se révélerait nécessaire (par exemple si
+    des outils plus avancés n'étaient pas disponibles). Le fichier
+    <filename>INSTALL</filename> correspond au <xref linkend="installation"/>,
+    avec quelques changements mineurs pour tenir compte de contextes différents.
+    Pour recréer le fichier, se placer dans le répertoire
+    <filename>doc/src/sgml</filename> et entrer la commande
+    <userinput>gmake INSTALL</userinput>.
    </para>
 
    <para>
-    Le fichier <filename>HISTORY</filename> peut être créé de manière similaire
-    en utilisant la commande <userinput>gmake HISTORY</userinput>. Pour le
-    fichier <filename>src/test/regress/README</filename>, la commande est
-    <userinput>gmake regress_README</userinput>.
+    Dans le passé, les notes de versions et les instructions pour les tests de
+    régression étaient aussi distribuées sous la forme de fichiers textes mais
+    ce n'est plus le cas.
    </para>
   </sect2>
 

postgresql/legal.xml

@@ -5,15 +5,15 @@
      révision $Revision$ -->
 
 <copyright>
- <year>1996-2013</year>
+ <year>1996-2014</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
 <legalnotice id="legalnotice">
  <title>Legal Notice</title>
 
  <para>
-  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2013
+  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2014
   by the PostgreSQL Global Development Group and is distributed under
   the terms of the license of the University of California below.
  </para>

postgresql/maintenance.xml

@@ -375,7 +375,7 @@
     <literal>FrozenXID</literal>. Ce XID ne suit pas les règles standards de
     comparaison des identifiants de transactions et est toujours considéré
     comme plus âgé que les XID normaux. Les XID normaux sont comparés sur une
-    base modulo-2<superscript>31</superscript>. Cela signifie
+    base modulo-2<superscript>32</superscript>. Cela signifie
     que pour chaque XID normal, il y en a deux milliards qui sont plus vieux et
     deux milliards qui sont plus récents. Une autre manière de le dire est que
     l'ensemble de définition des XID est circulaire et sans limite. De plus,

postgresql/plhandler.xml

@@ -187,7 +187,11 @@ CREATE LANGUAGE plsample
     argument est l'OID de la fonction, disponible dans le catalogue
     <classname>pg_proc</classname>. La fonction de validation doit récupérer
     cette ligne de la façon habituelle et réaliser les vérifications
-    appropriées. Les vérifications typiques incluent la vérification du
+    appropriées. Tout d'abord, elle appelle
+    <function>CheckFunctionValidatorAccess()</function> pour diagnostiquer les
+    appels explicites au validateur que l'utilisateur ne peut pas réaliser
+    via <command>CREATE FUNCTION</command>.
+    Les vérifications typiques incluent la vérification du
     support des types en arguments et en sortie, ainsi que la vérification
     syntaxique du corps de la requête pour ce langage. Si la fonction de
     validation est satisfait par la fonction, elle quitte sans erreur. Si, par
@@ -201,9 +205,12 @@ CREATE LANGUAGE plsample
     Les fonctions de validation devraient typiquement accepter le paramètre
     <xref linkend="guc-check-function-bodies"/>&nbsp;: s'il est désactivé,
     alors tout vérification coûteuse ou spécifique au contexte devrait être
-    abandonnée. En particulier, ce paramètre est désactivé par
+    abandonnée. Si le langage permet l'exécution de code à la compilation,
+    le validateur doit supprimer les vérifications qui impliquerait une
+    telle exécution. En particulier, ce paramètre est désactivé par
     <application>pg_dump</application>, pour qu'il puisse charger le langage
-    de procédures sans avoir à s'inquiéter des dépendances possibles dans le
+    de procédures sans avoir à s'inquiéter des effets de bord et des dépendances
+    possibles dans le
     corps des procédures stockées avec d'autres objets de la base de données.
     (À cause de cela, le gestionnaire d'appels doit éviter de supposer que la
     fonction de validation a vérifié complètement la fonction. Le but d'avoir

postgresql/ref/grant.xml

@@ -377,13 +377,15 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
   </para>
 
   <para>
-   Si <literal>WITH ADMIN OPTION</literal> est spécifié, le membre peut
-   à la fois en octroyer l'appartenance à d'autres rôles, et la révoquer.
-   Sans cette option, les utilisateurs ordinaires ne peuvent
-   pas le faire. Toutefois, les superutilisateurs peuvent
-   donner ou enlever à tout rôle l'appartenance à un rôle. Les rôles
-   qui possèdent le droit <literal>CREATEROLE</literal> peuvent agir ainsi sur tout rôle
-   qui n'est pas superutilisateur.
+   Si <literal>WITH ADMIN OPTION</literal> est spécifié, le membre peut à la
+   fois en octroyer l'appartenance à d'autres rôles, et la révoquer. Sans cette
+   option, les utilisateurs ordinaires ne peuvent pas le faire. Un rôle ne
+   dispose pas de l'option <literal>WITH ADMIN OPTION</literal> lui-même mais il
+   peut donner ou enlever son appartenance à partir d'une session où l'utilisateur
+   correspond au rôle. Les superutilisateurs peuvent donner ou supprimer
+   l'appartenance à tout rôle. Les rôles disposant de l'attribut
+   <literal>CREATEROLE</literal> peuvent donner ou supprimer l'appartenance à
+   tout rôle qui n'est pas un superutilisateur.
   </para>
 
   <para>

postgresql/ref/psql-ref.xml

@@ -94,8 +94,8 @@
       antislash. Du coup, vous ne pouvez pas mixer les commandes
       <acronym>SQL</acronym> et les méta-commandes
       <application>psql</application> avec cette option. Pour réussir ceci, vous
-      pouvez envoyer la chaîne dans un tube vers <application>psql</application>
-      comme ceci&nbsp;:
+      pouvez envoyer la chaîne dans un tube vers <application>psql</application>,
+      par exemple&nbsp;:
 <literal>echo "\x \\ SELECT * FROM foo;" | psql</literal>.
       (<literal>\\</literal> est la méta-commande séparateur.)
       </para>
@@ -106,7 +106,22 @@
        explicites sont inclues dans la chaîne pour la diviser en plusieurs
        transactions. Ceci est différent du comportement adopté quand la même
        chaîne est envoyée dans l'entrée standard de
-       <application>psql</application>.
+       <application>psql</application>. De plus, seul le résultat de la dernière
+       commande SQL est renvoyé.
+      </para>
+      <para>
+       À cause de ces comportements historiques, placer plus d'une commande dans
+       la chaîne fournie à l'option <option>-c</option> a souvent des résultats
+       inattendus. Il est préférable de fournir plusieurs commandes sur l'entrée
+       standard de <application>psql</application>, soit en utilisant
+       <application>echo</application> comme illustré ci-dessus, soit avec un
+       document shell en ligne, par exemple&nbsp;:
+<programlisting>
+psql &lt;&lt;EOF
+\x
+SELECT * FROM foo;
+EOF
+</programlisting>
       </para>
       </listitem>
     </varlistentry>

postgresql/regress.xml

@@ -53,25 +53,33 @@
    représente un problème sérieux.
   </para>
 
+  <warning>
    <para>
-    Comme cette méthode de tests fonctionne sur un serveur temporaire, elle 
-    ne fonctionnera pas en tant qu'utilisateur root (car le serveur refusera de
-    se lancer en tant qu'utilisateur root) Si vous avez lancé la construction en
-    tant que root, vous n'avez pas besoin de tout recommencer. À la place,
-    rendez le répertoire des tests de régression modifiable par un autre
-    utilisateur, devenez cet utilisateur et relancez les tests. Par exemple
-<screen><prompt>root# </prompt><userinput>chmod -R a+w src/test/regress</userinput>
-<prompt>root# </prompt><userinput>su - joeuser</userinput>
-<prompt>joeuser$ </prompt><userinput>cd <replaceable>répertoire construction haut niveau</replaceable></userinput>
-<prompt>joeuser$ </prompt><userinput>gmake check</userinput></screen>
-    (le seul <quote>risque en terme de sécurité</quote> est que les
-    autres utilisateurs pourraient modifier les résultats des tests de
-    régression dans votre dos. Utilisez le bon sens pour gérer les droits des
-    utilisateurs.)
+    Cette méthode démarre un serveur temporaire configuré pour accepter toute
+    connexion provenant de la machine locale. Tout utilisateur local peut
+    récupérer l'attribut superutilisateur en se connectant à ce serveur et
+    peut, en principe, exploiter tous les droits de l'utilisateur au niveau
+    système d'exploitation qui exécute ces tests. De ce fait, il n'est pas
+    recommandé d'utiliser <literal>gmake check</literal> sur des machines
+    partagées avec des utilisateurs non sûrs. À la place, exécutez les tests
+    après l'installation, comme décrit dans la section suivante.
    </para>
 
    <para>
-    Autrement, lancez les tests après l'installation.
+    Sur les machines Unix, ce danger peut être évité si le fichier de la socket
+    du serveur temporaire n'est pas accessible aux autres utilisateurs. Cela
+    arrive par exemple en exécutant les tests dans une prison (chroot). Sur
+    Windows, le serveur temporaire ouvre une socket TCP accessible en local,
+    donc les protections au niveau du système de fichiers ne peuvent pas aider.
+   </para>
+  </warning>
+
+    <para>
+    Comme cette méthode de tests exécute un serveur temporaire, cela ne
+    fonctionnera pas si vous avez construit le serveur en tant que root, étant
+    donné que le serveur ne démarre pas en tant que root. La procédure
+    recommandée est de ne pas construire en tant que root ou de réaliser les
+    tests après avoir terminé l'installation.
    </para>
 
    <para>