Mise à jour en version 9.3.16

postgresql/dml.xml

@@ -105,6 +105,18 @@ INSERT INTO produits (no_produit, nom, prix) VALUES
 </programlisting>
   </para>
 
+  <para>
+   Il est aussi possible d'insérer le résultat d'une requête (qui pourrait
+   renvoyer aucune ligne, une ligne ou plusieurs lignes)&nbsp;:
+<programlisting>
+INSERT INTO produits (no_produit, nom, prix)
+  SELECT no_produit, nom, prix FROM nouveaux_produits
+    WHERE date_sortie = 'today';
+</programlisting>
+   Ceci montre la grande puissance du mécanisme des requêtes SQL (<xref
+   linkend="queries"/>) sur le traitement des lignes à insérer.
+  </para>
+
   <tip>
    <para>
     Lors de l'insertion d'une grande quantité de données en même temps,
@@ -276,5 +288,97 @@ INSERT INTO produits (no_produit, nom, prix) VALUES
    manipulations&nbsp;!
   </para>
  </sect1>
-</chapter>
 
+ <sect1 id="dml-returning">
+  <title>Renvoyer des données provenant de lignes modifiées</title>
+
+  <indexterm zone="dml-returning">
+   <primary>RETURNING</primary>
+  </indexterm>
+
+  <indexterm zone="dml-returning">
+   <primary>INSERT</primary>
+   <secondary>RETURNING</secondary>
+  </indexterm>
+
+  <indexterm zone="dml-returning">
+   <primary>UPDATE</primary>
+   <secondary>RETURNING</secondary>
+  </indexterm>
+
+  <indexterm zone="dml-returning">
+   <primary>DELETE</primary>
+   <secondary>RETURNING</secondary>
+  </indexterm>
+
+  <para>
+   Parfois, il est intéressant d'obtenir des données de lignes modifiées
+   pendant qu'elles sont manipulées. Les commandes <command>INSERT</command>,
+   <command>UPDATE</command> et <command>DELETE</command> ont toutes une
+   clause <literal>RETURNING</literal> optionnelle qui le permet.
+   L'utilisation de la clause <literal>RETURNING</literal> évite l'exécution
+   d'une requête supplémentaire pour coller les données, et est
+   particulièrement intéressante quand il serait difficile d'identifier
+   autrement les lignes modifiées.
+  </para>
+
+  <para>
+   Le contenu autorisé d'une clause <literal>RETURNING</literal> est identique
+   à celui de la liste de sortie d'une commande <command>SELECT</command>
+   (voir <xref linkend="queries-select-lists"/>). Elle peut contenir les noms
+   des colonnes de la table cible ou des expressions utilisant ces colonnes.
+   Un raccourci habituel est <literal>RETURNING *</literal>, qui sélectionne
+   toutes les colonnes de la table cible, dans l'ordre de définition.
+  </para>
+
+  <para>
+   Avec un <command>INSERT</command>, les données disponibles à
+   <literal>RETURNING</literal> est la ligne qui a été insérée. Ceci n'est pas
+   utile pour les insertions simples car cela ne fera que répéter les données
+   fournies par le client mais cela peut devenir très utile si la commande se
+   base sur les valeurs calculées par défaut. Par exemple, lors de
+   l'utilisation d'une colonne <link
+   linkend="datatype-serial"><type>serial</type></link> fournissant des
+   identifiants uniques, <literal>RETURNING</literal> peut renvoyer
+   l'identifiant affecté à une nouvelle ligne&nbsp;:
+<programlisting>
+CREATE TABLE utilisateurs (prenom text, nom text, id serial primary key);
+
+INSERT INTO utilisateurs (prenom, nom) VALUES ('Joe', 'Cool') RETURNING id;
+</programlisting>
+   La clause <literal>RETURNING</literal> est aussi très utile avec un
+   <literal>INSERT ... SELECT</literal>
+  </para>
+
+  <para>
+   Dans un <command>UPDATE</command>, les données disponibles pour la clause
+   <literal>RETURNING</literal> correspondent au nouveau contenu de la ligne
+   modifiée. Par exemple&nbsp;:
+<programlisting>
+UPDATE produits SET prix = prix * 1.10
+  WHERE prix &lt;= 99.99
+  RETURNING nom, prix AS nouveau_prix;
+</programlisting>
+  </para>
+
+  <para>
+   Dans un <command>DELETE</command>, les données disponibles pour la clause
+   <literal>RETURNING</literal> correspondent au contenu de la ligne
+   supprimée. Par exemple&nbsp;:
+<programlisting>
+DELETE FROM produits
+  WHERE date_perime = 'today'
+  RETURNING *;
+</programlisting>
+  </para>
+
+  <para>
+   Si des triggers (<xref linkend="triggers"/>) sont définis sur la table
+   cible, les données disponibles pour la clause <literal>RETURNING</literal>
+   correspondent à la ligne modifiée par les triggers. De ce fait, une
+   utilisation courante de la clause <literal>RETURNING</literal> est
+   d'inspecter les colonnes calculées par les triggers.
+  </para>
+
+ </sect1>
+</chapter>

postgresql/func.xml

@@ -1320,12 +1320,13 @@ both</optional>
        </entry>
        <entry><type>text</type></entry>
        <entry>
-        Supprime la plus grande chaîne qui ne contient que les
-        <parameter>caractères</parameter> (une espace par défaut) à partir du
-        début, de la fin ou des deux extrémités (respectivement leading,
-	trailing, both) de la <parameter>chaîne</parameter>.
+        Supprime la plus grande chaîne qui ne contient que les caractères
+        compris dans <parameter>caractères</parameter> (une espace par défaut)
+        à partir du début, de la fin ou des deux extrémités
+        (<literal>both</literal> par défaut) de la
+        <parameter>chaîne</parameter>.
        </entry>
-       <entry><literal>trim(both 'x' from 'xTomxx')</literal></entry>
+       <entry><literal>trim(both 'xyz' from 'yxTomxx')</literal></entry>
        <entry><literal>Tom</literal></entry>
       </row>
 
@@ -1402,7 +1403,7 @@ both</optional>
         issus de <parameter>caractères</parameter> (une espace par défaut)
 	à partir du début et de la fin de <parameter>chaîne</parameter>.
        </entry>
-       <entry><literal>btrim('xyxtrimyyx', 'xy')</literal></entry>
+       <entry><literal>btrim('xyxtrimyyx', 'xyz')</literal></entry>
        <entry><literal>trim</literal></entry>
       </row>
 
@@ -1682,8 +1683,8 @@ both</optional>
         Supprime la chaîne la plus longue constituée uniquement de caractères
 	issus de <parameter>caractères</parameter> (une espace par défaut) à partir du début de la chaîne.
        </entry>
-       <entry><literal>ltrim('zzzytrim', 'xyz')</literal></entry>
-       <entry><literal>trim</literal></entry>
+       <entry><literal>ltrim('zzzytest', 'xyz')</literal></entry>
+       <entry><literal>test</literal></entry>
       </row>
 
       <row>
@@ -1970,8 +1971,8 @@ both</optional>
         caractères provenant de <parameter>caractères</parameter> (une espace par
         défaut) depuis la fin de <parameter>chaîne</parameter>.
        </entry>
-       <entry><literal>rtrim('trimxxxx', 'x')</literal></entry>
-       <entry><literal>trim</literal></entry>
+       <entry><literal>rtrim('testxxzx', 'xyz')</literal></entry>
+       <entry><literal>test</literal></entry>
       </row>
 
       <row>
@@ -3257,11 +3258,11 @@ binaires</title>
        </entry>
        <entry><type>bytea</type></entry>
        <entry>
-        Supprime la plus longue chaîne composée uniquement d'octets de
-        <parameter>octets</parameter> à partir du début et de la fin de
-        <parameter>chaîne</parameter>
+        Supprime la plus longue chaîne composée uniquement des octets
+        apparaissant dans <parameter>octets</parameter> à partir du début et
+        de la fin de <parameter>chaîne</parameter>
        </entry>
-       <entry><literal>trim(E'\\000'::bytea from E'\\000Tom\\000'::bytea)</literal></entry>
+       <entry><literal>trim(E'\\000\\001'::bytea from E'\\000Tom\\001'::bytea)</literal></entry>
        <entry><literal>Tom</literal></entry>
       </row>
      </tbody>
@@ -3305,11 +3306,11 @@ binaires</title>
        </entry>
        <entry><type>bytea</type></entry>
        <entry>
-        Supprime la plus longue chaîne constituée uniquement d'octets de
-        <parameter>octets</parameter> à partir du début et de la fin de
-        <parameter>chaîne</parameter>.
+        Supprime la plus longue chaîne constituée uniquement des octets
+        apparaissant dans <parameter>octets</parameter> à partir du début et
+        de la fin de <parameter>chaîne</parameter>.
       </entry>
-      <entry><literal>btrim( E'\\000trim\\000'::bytea, E'\\000'::bytea)</literal></entry>
+      <entry><literal>btrim(E'\\000trim\\001'::bytea, E'\\000\\001'::bytea)</literal></entry>
       <entry><literal>trim</literal></entry>
      </row>
 
@@ -6162,7 +6163,7 @@ MON')</literal> renvoie une erreur car <function>to_timestamp</function>
 
       <para>
        Exemple plus complexe&nbsp;: 
-       <literal>to_timestamp('15:12:02.020.001230', 'HH:MI:SS.MS.US')</literal>
+       <literal>to_timestamp('15:12:02.020.001230', 'HH24:MI:SS.MS.US')</literal>
        représente 15 heures, 12 minutes et (2 secondes + 20 millisecondes +
        1230 microsecondes =) 2,021230 secondes&nbsp;;
       </para>

postgresql/install-windows.xml

@@ -167,7 +167,7 @@
       supportée du <productname>Microsoft Windows SDK</productname>, il est
       recommandé de mettre à jour avec la dernière version supportée
       (actuellement la version 7.1), téléchargeable sur
-      <ulink url="http://www.microsoft.com/downloads/"></ulink>.
+      <ulink url="https://www.microsoft.com/download"></ulink>.
      </para>
      <para>
       Vous devez toujours inclure la partie <application>Windows Headers and

postgresql/legal.xml

@@ -4,18 +4,18 @@
      par      $Author$
      révision $Revision$ -->
 
-<date>2016</date>
+<date>2017</date>
 
 <copyright>
- <year>1996-2016</year>
+ <year>1996-2017</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
 <legalnotice id="legalnotice">
  <title>Legal Notice</title>
 
  <para>
-  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2016
+  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2017
   by the PostgreSQL Global Development Group.
  </para>
 

postgresql/mvcc.xml

@@ -653,16 +653,14 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
     </para>
 
     <para>
-    L'utilisation systématique de transactions Serializable peut
-    simplifier le développement. La garantie que n'importe quel jeu
-    de transactions concurrentes aura le même effet que si elles
-    s'exécutent une seule à la fois signifie que si vous pouvez
-    démontrer qu'une transaction seule, comme elle est écrite,
-    effectuera ce qui est attendu quand elle est exécutée seule, vous
-    pouvez être sûr qu'elle effectuera ce qui est attendu quelques
-    soient les autres transactions serializable qui s'exécutent en
-    même temps, même sans aucune information sur ce que ces autres
-    transactions pourraient faire. Il est important qu'un environnement
+    L'utilisation systématique de transactions Serializable peut simplifier le
+    développement. La garantie que tout ensemble de transactions Serializable
+    validées avec succès auront le même effet que si elles avaient été
+    exécutées une à la fois signifie que vous pouvez démontrer qu'une seule
+    transaction, telle qu'elle est écrite, aura le même bon résultat dans
+    n'importe quel mélange de transactions Serializable, même sans aucune
+    information sur ce que font les autres transactions. Il est important
+    qu'un environnement
     qui utilise cette technique ait une façon généralisée de
     traiter les erreurs de sérialisation (qui retournent toujours
     un SQLSTATE valant '40001'), parce qu'il sera très difficile de
@@ -676,6 +674,28 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
     choix en termes de performances pour certains environnements.
     </para>
 
+   <para>
+    Bien que le niveau d'isolation Serializable des transactions pour
+    <productname>PostgreSQL</productname> permet seulement à des transactions
+    parallèles de valider leurs modifications que s'il est prouvé qu'un ordre
+    d'exécution en série produirait le même résultat, cela n'empêche pas
+    toujours la montée d'erreurs qui ne surviendrait pas dans une véritable
+    exécution en série. En particulier, il est possible de voir des violations
+    de contraintes uniques causées par des conflits sur des transactions
+    Serializable qui se surchargent même après avoir vérifié explicitement que
+    la clé n'est pas présente avant de tenter son insertion. Ceci peut
+    s'éviter en s'assurant que <emphasis>toutes</emphasis> les transactions
+    Serializable qui peuvent insérer des clés en conflit vérifient
+    explicitement avant si elles peuvent l'insérer. Par exemple, imaginez une
+    application qui demande à un utilisateur une nouvelle clé, puis vérifie si
+    elle n'existe pas déjà, ou génère une nouvelle clé en sélectionne la clé
+    maximale déjà existante et en ajoutant la suivante. Si certaines
+    transactions Serializable insèrent de nouvelles clés directement sans
+    suivre ce protocole, les violations de contraintes uniques doivent être
+    reportées même dans les cas où elles ne pourraient pas survenir dans le
+    cas d'une exécution en série de transactions concurrentes.
+   </para>
+
    <para>
     Pour une performance optimale quand on s'appuie sur les transactions
     Serializable pour le contrôle de la concurrence, ces points doivent

postgresql/pgstattuple.xml

@@ -111,6 +111,17 @@ free_percent       | 1.95
      </tgroup>
     </table>
 
+    <note>
+      <para>
+        La valeur de la colonne <literal>table_len</literal> sera toujours
+        supérieur à la somme des colonnes <literal>tuple_len</literal>,
+        <literal>dead_tuple_len</literal> et <literal>free_space</literal>. La
+        différence correspond aux données systèmes comme la table de pointeurs
+        vers les lignes (une table par bloc) et aux octets d'alignements
+        permettant de s'assurer que les lignes sont correctement alignées.
+      </para>
+    </note>
+
     <para>
      <function>pgstattuple</function> acquiert seulement un verrou en lecture
      sur la relation. Donc les relations ne reflètent pas une image