Mise à jour en version 9.5.24

postgresql/advanced.xml

@@ -626,22 +626,22 @@ CREATE VIEW villes AS
 );
 
 CREATE TABLE capitales (
-  etat      char(2)
+  etat      char(2) UNIQUE NOT NULL
 ) INHERITS (villes);</programlisting>
    </para>
 
    <para>
     Dans ce cas, une ligne de <classname>capitales</classname>
     <firstterm>hérite</firstterm> de toutes les colonnes
     (<structfield>nom</structfield>, <structfield>population</structfield> et
-    <structfield>elevation</structfield>) de son <firstterm>parent</firstterm>,
-    <classname>villes</classname>. Le type de la colonne
-    <structfield>nom</structfield> est <type>text</type>, un type natif de
-    <productname>PostgreSQL</productname> pour les chaînes de caractères à
-    longueur variable. La table <classname>capitales</classname> a une colonne supplémentaire,
-    <structfield>etat</structfield>, qui affiche l'état dont elles sont la
-    capitale. Sous <productname>PostgreSQL</productname>, une table peut
-    hériter de zéro à plusieurs autres tables.
+    <structfield>elevation</structfield>) de son
+    <firstterm>parent</firstterm>, <classname>villes</classname>. Le type de
+    la colonne <structfield>nom</structfield> est <type>text</type>, un type
+    natif de <productname>PostgreSQL</productname> pour les chaînes de
+    caractères à longueur variable. La table <classname>capitales</classname>
+    a une colonne supplémentaire, <structfield>etat</structfield>, qui affiche
+    l'abréviation de cet état. Sous <productname>PostgreSQL</productname>, une
+    table peut hériter de zéro à plusieurs autres tables.
    </para>
 
    <para>

postgresql/biblio.xml

@@ -146,8 +146,8 @@
   </biblioentry>
 
   <biblioentry id="ull88">
-   <title>Principles of Database and Knowledge</title>
-   <subtitle>Base Systems</subtitle>
+   <title>Principles of Database and Knowledge-Base Systems</title>
+   <subtitle>Classical Database Systems</subtitle>
    <titleabbrev>Ullman, 1988</titleabbrev>
    <authorgroup>
     <author>

postgresql/catalogs.xml

@@ -8360,14 +8360,15 @@
    Il existe plusieurs types distincts d'objets verrouillables : les
    relations complètes (tables, par exemple), les pages individuelles de
    relations, des tuples individuels de relations, les identifiants de
-   transaction (virtuels et permanents) et les objets généraux de la base
-   de données (identifiés par
-   l'OID de la classe et l'OID de l'objet, de la même façon que dans
-   <structname>pg_description</structname> ou
+   transaction (virtuels et permanents) et les objets généraux de la base de
+   données (identifiés par l'OID de la classe et l'OID de l'objet, de la même
+   façon que dans <structname>pg_description</structname> ou
    <structname>pg_depend</structname>). De plus, le droit d'étendre une
-   relation est représenté comme un objet verrouillable distinct. Et
-   enfin, les verrous informatifs peuvent être pris sur les numéros qui
-   ont la signification définie par l'utilisateur.
+   relation est représenté comme un objet verrouillable distinct, tout comme
+   le droit de mettre à jour
+   <structname>pg_database</structname>.<structfield>datfrozenxid</structfield>.
+   Et enfin, les verrous informatifs peuvent être pris sur les numéros qui ont
+   la signification définie par l'utilisateur.
   </para>
 
   <table>
@@ -8395,6 +8396,7 @@
        Type de l'objet verrouillable&nbsp;:
        <literal>relation</literal>,
        <literal>extend</literal>,
+       <literal>frozenid</literal>,
        <literal>page</literal>,
        <literal>tuple</literal>,
        <literal>transactionid</literal>,

postgresql/config.xml

@@ -5081,6 +5081,8 @@ CREATE TABLE postgres_log
  <programlisting>
 COPY postgres_log FROM '/chemin/complet/vers/le/logfile.csv' WITH csv;
  </programlisting>
+ Il est aussi possible d'accéder au fichier en tant que table externe
+ en utilisant le module <xref linkend="file-fdw"/>.
 </para>
 
 <para>

postgresql/datatype.xml

@@ -2175,7 +2175,7 @@ des références au 1er janvier 2000 ?
      </para>
     </sect3>
 
-    <sect3>
+    <sect3 id="datatype-datetime-special-values">
      <title>Valeurs spéciales</title>
 
      <indexterm>
@@ -2266,13 +2266,28 @@ des références au 1er janvier 2000 ?
        l'heure courante pour le type de données correspondant&nbsp;:
        <literal>CURRENT_DATE</literal>, <literal>CURRENT_TIME</literal>,
        <literal>CURRENT_TIMESTAMP</literal>, <literal>LOCALTIME</literal>,
-       <literal>LOCALTIMESTAMP</literal>. Les quatre dernières acceptent une
-       indication optionnelle de précision en dessous de la seconde (voir
+       <literal>LOCALTIMESTAMP</literal>. (Voir
        la <xref linkend="functions-datetime-current"/>). Ce
        sont là des fonctions SQL qui ne sont <emphasis>pas</emphasis> reconnues
        comme chaînes de saisie de données.
       </para>
 
+      <caution>
+       <para>
+        Bien qu'il n'y ait pas de problèmes à utiliser les chaînes
+        <literal>now</literal>, <literal>today</literal>,
+        <literal>tomorrow</literal> et <literal>yesterday</literal> dans des
+        commandes SQL interactives, elles peuvent avoir un comportement
+        surprenant quand la commande est sauvegardée pour une exécution
+        ultérieure, par exemple dans des requêtes préparées, des vues ou des
+        fonctions. La châine peut être convertie en une valeur spécifique qui
+        continue à être utilisée bien après qu'elle ne soit éculée. Dans de
+        tels contextes, utilisez plutôt une des fonctions SQL. Par exemple,
+        <literal>CURRENT_DATE + 1</literal> est plus sûr que
+        <literal>'tomorrow'::date</literal>.
+       </para>
+      </caution>
+
     </sect3>
    </sect2>
 

postgresql/dblink.xml

@@ -176,7 +176,7 @@ CREATE USER dblink_regression_test WITH PASSWORD 'secret';
   OK
  (1 row)
 
- SELECT * FROM dblink('myconn','SELECT * FROM foo') AS t(a int, b text, c text[]);
+ SELECT * FROM dblink('myconn', 'SELECT * FROM foo') AS t(a int, b text, c text[]);
   a  | b |       c
  ----+---+---------------
    0 | a | {a0,b0,c0}
@@ -637,7 +637,7 @@ SELECT * FROM dblink('myconn', 'select proname, prosrc from pg_proc')
       <para>
        La commande SQL à exécuter sur la base de données
        distante&nbsp;; par exemple
-       <literal>INSERT INTO foo VALUES(0,'a','{"a0","b0","c0"}')</literal>.
+       <literal>INSERT INTO foo VALUES(0, 'a', '{"a0","b0","c0"}')</literal>.
       </para>
      </listitem>
     </varlistentry>
@@ -676,7 +676,7 @@ SELECT dblink_connect('dbname=dblink_test_standby');
  OK
 (1 row)
 
-SELECT dblink_exec('insert into foo values(21,''z'',''{"a0","b0","c0"}'');');
+SELECT dblink_exec('insert into foo values(21, ''z'', ''{"a0","b0","c0"}'');');
    dblink_exec
 -----------------
  INSERT 943366 1
@@ -688,7 +688,7 @@ SELECT dblink_connect('myconn', 'dbname=regression');
  OK
 (1 row)
 
-SELECT dblink_exec('myconn', 'insert into foo values(21,''z'',''{"a0","b0","c0"}'');');
+SELECT dblink_exec('myconn', 'insert into foo values(21, ''z'', ''{"a0","b0","c0"}'');');
    dblink_exec
 ------------------
  INSERT 6432584 1

postgresql/file-fdw.xml

@@ -26,7 +26,8 @@
 
    <listitem>
     <para>
-     Spécifie le fichier devant être lu. Requis. Doit être un chemin absolu.
+     Spécifie le fichier devant être lu. Requis. Les chemins relatifs sont
+     compris comme provenant du répertoire principal de données.
     </para>
    </listitem>
   </varlistentry>
@@ -190,7 +191,8 @@
   <para>
    Une des utilisations évidentes de <literal>file_fdw</literal> est de rendre
    les journaux applicatifs de PostgreSQL disponibles sous la forme d'une table.
-   Pour faire cela, vous devez tout d'abord journaliser les traces au format CSV.
+   Pour faire cela, vous devez tout d'abord <link
+   linkend="runtime-config-logging-csvlog">journaliser les traces au format CSV</link>.
    Nous appelerons le fichier de traces <literal>pglog.csv</literal>.
    Tout d'abord, installez l'extension <literal>file_fdw</literal>&nbsp;:
   </para>

postgresql/func.xml

@@ -502,7 +502,8 @@
 
       <row>
        <entry><literal>!</literal> </entry>
-       <entry>factoriel</entry>
+       <entry>factoriel
+        (obsolète, utilisez <function>factorial()</function> à la place)</entry>
        <entry><literal>5 !</literal></entry>
        <entry><literal>120</literal></entry>
       </row>
@@ -700,6 +701,19 @@
        <entry><literal>2.71828182845905</literal></entry>
       </row>
 
+      <row>
+       <entry>
+        <indexterm>
+         <primary>factorial</primary>
+        </indexterm>
+        <literal><function>factorial(<type>bigint</type>)</function></literal>
+       </entry>
+       <entry><type>numeric</type></entry>
+       <entry>factoriel</entry>
+       <entry><literal>factorial(5)</literal></entry>
+       <entry><literal>120</literal></entry>
+      </row>
+
       <row>
        <entry>
         <indexterm>
@@ -6147,8 +6161,19 @@ SELECT regexp_matches('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
 
     <listitem>
      <para>
-      la conversion <literal>YYYY</literal> d'une chaîne en champ de type
-      <type>timestamp</type> ou <type>date</type> comporte une restriction
+      Dans <function>to_timestamp</function> et <function>to_date</function>,
+      les années négatives sont traitées comme signifiant avant Jésus Christ.
+      Si vous écrivez à la fois une année négative et un champ
+      <literal>BC</literal> explicite, vous obtenez après Jésus Chrisft de
+      nouveau. Une entrée année zéro est traitée comme l'année 1 après Jésus
+      Christ.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Dans <function>to_timestamp</function> et <function>to_date</function>,
+      la conversion <literal>YYYY</literal> comporte une restriction
       avec les années à plus de quatre chiffres. Il faut alors utiliser un
       modèle ou un caractère non numérique après <literal>YYYY</literal>,
       sans quoi l'année est toujours interprétée sur
@@ -8126,20 +8151,22 @@ now()
          De ce fait, les trois instructions suivantes renvoient le même résultat&nbsp;:
          <programlisting>SELECT CURRENT_TIMESTAMP;
 SELECT now();
-SELECT TIMESTAMP 'now'; -- utilisation incorrecte avec DEFAULT</programlisting>
+SELECT TIMESTAMP 'now'; -- mais voir l'astuce ci-dessous</programlisting>
    </para>
 
     <tip>
      <para>
-      La troisième forme ne doit pas être utilisée pour la spécification
-      de la clause <literal>DEFAULT</literal> à la création d'une table. Le système
+      Ne pas utiliser la troisième forme lors de la spécification d'une valeur
+      à évaluer ultérieurement, par exemple dans une clause
+      <literal>DEFAULT</literal> de la colonne d'une table.  Le système
       convertirait <literal>now</literal> en valeur de type
-      <type>timestamp</type> dès l'analyse de la constante. À chaque fois que la
-      valeur par défaut est nécessaire, c'est l'heure de création de la
+      <type>timestamp</type> dès l'analyse de la constante. À chaque fois que
+      la valeur par défaut est nécessaire, c'est l'heure de création de la
       table qui est alors utilisée. Les deux premières formes ne sont pas
-      évaluées avant l'utilisation de la valeur par défaut, il s'agit
-      d'appels de fonctions. C'est donc bien le comportement attendu, l'heure
-      d'insertion comme valeur par défaut, qui est obtenu.
+      évaluées avant l'utilisation de la valeur par défaut, il s'agit d'appels
+      de fonctions. C'est donc bien le comportement attendu, l'heure
+      d'insertion comme valeur par défaut, qui est obtenu. (Voir aussi <xref
+      linkend="datatype-datetime-special-values"/>.)
      </para>
     </tip>
   </sect2>
@@ -11889,10 +11916,17 @@ END</synopsis>
    valeur par défaut aux valeurs NULL lorsque la donnée est récupérée pour
    affichage. Par exemple&nbsp;:
 <programlisting>SELECT COALESCE(description, description_courte, '(aucune)') ...</programlisting>
-   Cela renvoie <varname>description</varname> si sa valeur est non NULL. Sinon
-   <varname>courte_description</varname> s'il est lui-même non NULL, et enfin <literal>(none)</literal>.
+   Cela renvoie <varname>description</varname> si sa valeur est non NULL.
+   Sinon <varname>courte_description</varname> s'il est lui-même non NULL, et
+   enfin <literal>(aucune)</literal>.
   </para>
 
+   <para>
+    Les arguments doivent tous être convertible vers un type de données
+    commun, qui* sera le type du résultat (voir <xref
+    linkend="typeconv-union-case"/> pour les détails).
+   </para>
+
    <para>
     À l'instar d'une expression <token>CASE</token>, <function>COALESCE</function>
     n'évalue pas les arguments inutiles à la détermination du
@@ -11921,13 +11955,30 @@ END</synopsis>
    On peut s'en servir pour effectuer l'opération inverse de l'exemple de
    <function>COALESCE</function> donné ci-dessus&nbsp;:
 <programlisting>SELECT NULLIF(valeur, '(aucune)') ...</programlisting>
-  </para>
-  <para>
    Dans cet exemple, si <literal>valeur</literal> vaut
    <literal>(aucune)</literal>, la valeur NULL est renvoyée, sinon la valeur de
    <literal>valeur</literal> est renvoyée.
   </para>
 
+  <para>
+   Les deux arguments doit être de types comparables. Pour être spécifique,
+   ils sont comparés exactement comme si vous aviez écrit
+   <literal><replaceable>value1</replaceable>
+   = <replaceable>value2</replaceable></literal>, donc il doit y avoir un
+   opérateur <literal>=</literal> convenable de disponible.
+  </para>
+
+  <para>
+   Le résultat a le même type que le premier argument &mdash; mais il existe
+   une subtilité. Ce qui est réellement renvoyé est le premier argument de
+   l'opérateur <literal>=</literal> impliqué et, dans certains cas, aura été
+   promu pour correspondre au type du deuxième argument. Par exemple,
+   <literal>NULLIF(1, 2.2)</literal> renvoie <type>numeric</type> parce qu'il
+   n'y a pas d'opérateur <type>integer</type> <literal>=</literal>
+   <type>numeric</type>, seulement un <type>numeric</type>
+   <literal>=</literal> <type>numeric</type>.
+  </para>
+
   </sect2>
 
   <sect2 id="functions-greatest-least">

postgresql/high-availability.xml

@@ -1320,7 +1320,8 @@ primary_slot_name = 'node_a_slot'
      If <varname>archive_mode</varname> is set to <literal>on</literal>, the
      archiver is not enabled during recovery or standby mode. If the standby
      server is promoted, it will start archiving after the promotion, but
-     will not archive any WAL it did not generate itself. To get a complete
+     will not archive any WAL or timeline history files that
+     it did not generate itself. To get a complete
      series of WAL files in the archive, you must ensure that all WAL is
      archived, before it reaches the standby. This is inherently true with
      file-based log shipping, as the standby can only restore files that
@@ -2336,13 +2337,14 @@ LOG:  database system is ready to accept read only connections
    </para>
 
    <para>
-    Le processus d'écriture en arrière plan (background writer) est actif durant
-    la récupération et effectuera les restartpoints (points de reprise)
-    (similaires aux points de synchronisation ou checkpoints sur le primaire) et
-    les activités normales de nettoyage de blocs. Ceci peut inclure la mise à jour
-    des information de hint bit des données du serveur de standby.
-    La commande <command>CHECKPOINT</command>  est acceptée pendant la récupération,
-    bien qu'elle déclenche un restartpoint et non un checkpoint.
+    Les processus d'écriture en arrière plan (checkpointer et background
+    writer) sont actifs durant la récupération. Le processus checkpointer
+    effectuera les restartpoints (similaire aux checkpoints sur le primaire)
+    et le processus background writer  effectuera les activités normales de
+    nettoyage de blocs. Ceci peut inclure la mise à jour des information de
+    hint bit des données du serveur de standby. La commande
+    <command>CHECKPOINT</command>  est acceptée pendant la récupération, bien
+    qu'elle déclenche un restartpoint et non un checkpoint.
    </para>
   </sect2>
 

postgresql/libpq.xml

@@ -93,22 +93,6 @@
     </para>
    </warning>
 
-   <note>
-    <para>
-     Sur Windows, il existe un moyen pour améliorer les performances si une
-     connexion seule à la base de données est ouverte puis fermée de façon
-     répétée. En interne, libpq appelle <function>WSAStartup()</function> et
-     <function>WSACleanup()</function> respectivement pour le début et la fin
-     de la transaction. <function>WSAStartup()</function> incrémente un
-     compteur de référence interne à la bibliothèque Windows.
-     Ce compteur est décrémenté par <function>WSACleanup()</function>. Quand le compteur arrive à
-     un, appeler <function>WSACleanup()</function> libère toutes les ressources et toutes les DLL
-     associées. C'est une opération coûteuse. Pour éviter cela, une application
-     peut appeler manuellement <function>WSAStartup()</function> afin que les ressources ne soient
-     pas libérées quand la dernière connexion est fermée.
-    </para>
-   </note>
-
    <variablelist>
     <varlistentry id="libpq-pqconnectdbparams">
      <term><function>PQconnectdbParams</function><indexterm><primary>PQconnectdbParams</primary></indexterm></term>
@@ -7128,7 +7112,7 @@ description:sslmode=require
      <row>
       <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
       <entry>certificat client</entry>
-      <entry>requis par le serveur</entry>
+      <entry>envoyé par le serveur</entry>
      </row>
 
      <row>
@@ -7333,14 +7317,6 @@ description:sslmode=require
   de faire un verrouillage coopératif entre <application>libpq</application> et
   votre application.
  </para>
-
- <para>
-  Si vous expérimentez des problèmes avec les applications utilisant des threads,
-  lancez le programme dans <filename>src/tools/thread</filename> pour voir si votre
-  plateforme à des fonctions non compatibles avec les threads. Ce programme
-  est lancé par <filename>configure</filename> mais, dans le cas des
-  distributions binaires, votre bibliothèque pourrait ne pas correspondre à la bibliothèque utilisée pour construire les binaires.
- </para>
 </sect1>