Mise à jour en version 9.4.19

postgresql/acronyms.xml

@@ -76,7 +76,7 @@
     <term><acronym>CPAN</acronym></term>
     <listitem>
      <para>
-      <ulink url="http://www.cpan.org/">Comprehensive Perl Archive
+      <ulink url="https://www.cpan.org/">Comprehensive Perl Archive
        Network</ulink>, réseau d'archives Perl
      </para>
     </listitem>

postgresql/backup.xml

@@ -146,7 +146,7 @@
     <literal>ON_ERROR_STOP</literal> configurée pour modifier ce comportement.
     <application>psql</application> quitte alors avec un
     code d'erreur 3 si une erreur SQL survient&nbsp;:
-<programlisting>psql --set ON_ERROR_STOP=on base_de_données &lt; fichier_sauvegarde
+<programlisting>psql --set ON_ERROR_STOP=on <replaceable>base_de_données</replaceable> &lt; <replaceable>fichier_sauvegarde</replaceable>
    </programlisting>
    Dans tous les cas, une sauvegarde partiellement restaurée est obtenue.
    Si cela n'est pas souhaitable, il est possible d'indiquer que la sauvegarde
@@ -1180,7 +1180,7 @@ SELECT pg_start_backup('label', true);
    <para>
     Tous les fichiers demandés ne seront pas des segments WAL&nbsp;; vous
     pouvez aussi vous attendre à des demandes de fichiers suffixés par
-    <literal>.backup</literal> or <literal>.history</literal>. Il faut également
+    <literal>.history</literal>. Il faut également
     garder à l'esprit que le nom de base du chemin <literal>%p</literal>
     diffère de <literal>%f</literal>&nbsp;; il ne sont pas interchangeables.
    </para>

postgresql/datatype.xml

@@ -522,16 +522,14 @@
    </para>
 
    <para>
-    Dans ce qui suit, on utilise les termes suivants&nbsp;:
-    l'<firstterm>échelle</firstterm> d'un <type>numeric</type> est le
-    nombre de chiffres décimaux de la partie fractionnaire, à droite du
-    séparateur de décimales. La
-    <firstterm>précision</firstterm> d'un <type>numeric</type> est le
-    nombre total de chiffres significatifs dans le nombre complet,
-    c'est-à-dire le nombre de chiffres de part et d'autre du séparateur.
-    Donc, le nombre 23.5141
-    a une précision de 6 et une échelle de 4. On peut considérer que
-    les entiers ont une échelle de 0.
+    Dans ce qui suit, on utilise les termes suivants&nbsp;: la
+    <firstterm>précision</firstterm> d'un <type>numeric</type> est le nombre
+    total de chiffres significatifs dans le nombre complet, c'est-à-dire le
+    nombre de chiffres de part et d'autre du séparateur.
+    L'<firstterm>échelle</firstterm> d'un <type>numeric</type> est le nombre
+    de chiffres décimaux de la partie fractionnaire, à droite du séparateur de
+    décimales. Donc, le nombre 23.5141 a une précision de 6 et une échelle de
+    4. On peut considérer que les entiers ont une échelle de 0.
    </para>
 
    <para>
@@ -2766,17 +2764,6 @@ P <optional> <replaceable>années</replaceable>-<replaceable>mois</replaceable>-
      explicite à chaque partie, si au moins un champ est négatif.
     </para>
 
-    <para>
-     De façon interne, les valeurs de type <type>interval</type> sont stockées
-     comme mois, jours et secondes. C'est ainsi parce que le nombre de jours
-     d'un mois varie, et un jour peut avoir 23 ou 25 heures si des changements d'heures
-     sont impliqués. Les champs mois et jours sont des entiers, alors que le champ secondes
-     peut stocker des nombres décimaux. Les intervalles étant habituellement créés à partir de chaînes
-     constantes ou de soustractions de <type>timestamps</type>, cette méthode fonctionne bien
-     dans la plupart des cas. Les fonctions <function>justify_days</function> et <function>justify_hours</function>
-     sont disponibles pour ajuster les jours et heures qui dépassent leurs portées habituelles.
-    </para>
-
     <para>
      Dans le format verbeux de saisie, et dans certains champs des formats
      plus compacts, les valeurs de champs peuvent avoir des parties décimales&nbsp;;
@@ -2829,6 +2816,32 @@ P <optional> <replaceable>années</replaceable>-<replaceable>mois</replaceable>-
      </tgroup>
     </table>
 
+    <para>
+     De façon interne, les valeurs de type <type>interval</type> sont stockées
+     comme mois, jours et secondes. C'est ainsi parce que le nombre de jours
+     d'un mois varie, et un jour peut avoir 23 ou 25 heures si des changements
+     d'heures sont impliqués. Les champs mois et jours sont des entiers, alors
+     que le champ secondes peut stocker des nombres décimaux. Les intervalles
+     étant habituellement créés à partir de chaînes constantes ou de
+     soustractions de <type>timestamps</type>, cette méthode fonctionne bien
+     dans la plupart des cas, mais peut être la cause de résultats
+     inattendus&nbsp;:
+
+     <programlisting>SELECT EXTRACT(hours from '80 minutes'::interval);
+ date_part
+-----------
+         1
+
+SELECT EXTRACT(days from '80 hours'::interval);
+ date_part
+-----------
+         0</programlisting>
+
+      Les fonctions <function>justify_days</function> et
+      <function>justify_hours</function> sont disponibles pour ajuster les
+      jours et heures qui dépassent leurs portées habituelles.
+    </para>
+
    </sect2>
 
    <sect2 id="datatype-interval-output">

postgresql/ddl.xml

@@ -1891,29 +1891,33 @@ ALTER TABLE produits ADD FOREIGN KEY (id_groupe_produit) REFERENCES groupes_prod
        <replaceable>utilisateur</replaceable> SET search_path =
        "$utilisateur"</literal>. Tous conservent la possibilité de créer des
        objets dans le schéma public mais seuls les noms qualifiés choisiront
-       ces objets. Un utilisant disposant de l'attribut
-       <literal>CREATEROLE</literal> peut enlever cette configuration et
-       exécuter n'importe quel requête sous l'identité des utilisateurs se
-       basant sur cette configuration. Si vous donnez l'attribut
-       <literal>CREATEROLE</literal> à des utilisateurs sans garantie sur
-       cette capacité pratiquement équivalente à l'attribut superutilisateur,
-       utilisez plutôt la première méthode.
+       ces objets. Bien que les références qualifiées aux tables sont
+       correctes, les appels aux fonctions du schéma public <link
+       linkend="typeconv-func">ne seront pas sûrs ou fiables</link>.  De plus,
+       un utilisateur disposant de l'attribut <literal>CREATEROLE</literal>
+       peut enlever cette configuration et exécuter n'importe quel requête
+       sous l'identité des utilisateurs se basant sur cette configuration. Si
+       vous créez des fonctions ou extensions dans le schéma public ou si vous
+       donnez l'attribut <literal>CREATEROLE</literal> à des utilisateurs sans
+       garantie sur cette capacité pratiquement équivalente à l'attribut
+       superutilisateur, utilisez plutôt la première méthode.
       </para>
      </listitem>
 
      <listitem>
       <para>
        Supprimer le schéma public du <varname>search_path</varname> dans <link
-       linkend="config-setting-configuration-
-       file"><filename>postgresql.conf</filename></link>. La conséquence pour
-       l'utilisateur correspond à celle de la méthode précédente. En plus des
-       implications pour le <literal>CREATEROLE</literal>, cela demande de
-       faire confiance aux propriétaires des bases de données de la même
-       façon. Si vous affectez l'attribut <literal>CREATEROLE</literal>,
-       l'attribut <literal>CREATEDB</literal> ou la propriété d'une base de
-       données à des utilisateurs sans garantie sur cette capacité
-       pratiquement équivalente à l'attribut superutilisateur, utilisez plutôt
-       la première méthode.
+       linkend="config-setting-configuration-file"><filename>postgresql.conf</filename></link>.
+       La conséquence pour l'utilisateur correspond à celle de la méthode
+       précédente. En plus des implications pour les fonctions et pour le
+       <literal>CREATEROLE</literal>, cela demande de faire confiance aux
+       propriétaires des bases de données comme pour les utilisateurs ayant
+       l'attribut <literal>CREATEROLE</literal>. Si vous créez des fonctions
+       ou des extensions dans le schéma public ou si vous affectez l'attribut
+       <literal>CREATEROLE</literal>, l'attribut <literal>CREATEDB</literal>
+       ou la propriété d'une base de données à des utilisateurs sans garantie
+       sur cette capacité pratiquement équivalente à l'attribut
+       superutilisateur, utilisez plutôt la première méthode.
       </para>
      </listitem>
 

postgresql/ecpg.xml

@@ -1645,7 +1645,7 @@ while (1)
      Voici un exemple utilisant le type de données <type>complex</type>
      de l'exemple tiré de <xref linkend="xtypes"/>. La représentation
      externe sous forme de chaîne de ce type est
-     <literal>(%lf,%lf)</literal>, qui est définie dans les fonctions
+     <literal>(%f,%f)</literal>, qui est définie dans les fonctions
      <function>complex_in()</function> et <function>complex_out()</function>.
      L'exemple suivant insère les valeurs de type complexe
      <literal>(1,1)</literal> et <literal>(3,3)</literal> dans les colonnes
@@ -1918,10 +1918,23 @@ EXEC SQL SELECT started, duration INTO :ts1, :iv1 FROM datetbl WHERE d=:date1;
 PGTYPEStimestamp_add_interval(&ts1, &iv1, &tsout);
 out = PGTYPEStimestamp_to_asc(&tsout);
 printf("Started + duration: %s\n", out);
-free(out);
-]]>
-   </programlisting>
+PGTYPESchar_free(out);
+ ]]>
+ </programlisting>
   </para>
+
+  <sect2 id="ecpg-pgtypes-cstrings">
+   <title>Chaînes de caractères</title>
+   <para>
+    Certaines fonctions comme <function>PGTYPESnumeric_to_asc</function>
+    renvoient un pointeur vers une chaîne de caractères tout juste allouée.
+    Ces résultats devraient être libérés avec
+    <function>PGTYPESchar_free</function> au lieu de
+    <function>free</function>. (Ceci est seulement important sur Windows où
+    l'allocation et la libération de la mémoire ont parfois besoin d'être
+    réalisées par la même bibliothèque.)
+   </para>
+  </sect2>
 
   <sect2 id="ecpg-pgtypes-numeric">
    <title>Le TYpe numeric</title>
@@ -1996,6 +2009,8 @@ char *PGTYPESnumeric_to_asc(numeric *num, int dscale);
         </synopsis>
         La valeur numérique sera affichée avec <literal>dscale</literal> chiffres
         décimaux, et sera arrondie si nécessaire.
+        Le résultat doit être libéré avec
+        <function>PGTYPESchar_free()</function>.
        </para>
       </listitem>
      </varlistentry>
@@ -2389,9 +2404,11 @@ date PGTYPESdate_from_asc(char *str, char **endptr);
         <synopsis>
 char *PGTYPESdate_to_asc(date dDate);
         </synopsis>
-        La fonction reçoit la date <literal>dDate</literal> comme unique paramètre.
-        Elle retournera la date dans la forme <literal>1999-01-18</literal>, c'est-à-dire
-        le format <literal>YYYY-MM-DD</literal>.
+        La fonction reçoit la date <literal>dDate</literal> comme unique
+        paramètre. Elle retournera la date dans la forme
+        <literal>1999-01-18</literal>, c'est-à-dire le format
+        <literal>YYYY-MM-DD</literal>. Le résultat doit être libéré avec
+        <function>PGTYPESchar_free()</function>.
        </para>
       </listitem>
      </varlistentry>
@@ -2816,9 +2833,10 @@ timestamp PGTYPEStimestamp_from_asc(char *str, char **endptr);
         <synopsis>
 char *PGTYPEStimestamp_to_asc(timestamp tstamp);
         </synopsis>
-        Cette fonction reçoin le timestamp <literal>tstamp</literal> comme
+        Cette fonction reçoit le timestamp <literal>tstamp</literal> comme
         seul argument et retourne une chaîne allouée qui contient la
-        représentation textuelle du timestamp.
+        représentation textuelle du timestamp. Le résultat doit être libéré
+        avec <function>PGTYPESchar_free()</function>.
        </para>
       </listitem>
      </varlistentry>
@@ -3326,9 +3344,11 @@ interval *PGTYPESinterval_from_asc(char *str, char **endptr);
         <synopsis>
 char *PGTYPESinterval_to_asc(interval *span);
         </synopsis>
-        Cette fonction convertit la variable interval vers laquelle <literal>span</literal>
-        pointe vers un char* C. La sortie ressemble à cet exemple:
-        <literal>@ 1 day 12 hours 59 mins 10 secs</literal>.
+        Cette fonction convertit la variable interval vers laquelle
+        <literal>span</literal> pointe vers un char* C. La sortie ressemble à
+        cet exemple: <literal>@ 1 day 12 hours 59 mins 10 secs</literal>. Le
+        résultat doit être libéré avec
+        <function>PGTYPESchar_free()</function>.
        </para>
       </listitem>
      </varlistentry>

postgresql/external-projects.xml

@@ -68,7 +68,7 @@
       <entry>DBD::Pg</entry>
       <entry>Perl</entry>
       <entry>Pilote DBI Perl</entry>
-      <entry><ulink url="http://search.cpan.org/dist/DBD-Pg/">http://search.cpan.org/dist/DBD-Pg/</ulink></entry>
+      <entry><ulink url="https://metacpan.org/release/DBD-Pg/">https://metacpan.org/release/DBD-Pg/</ulink></entry>
      </row>
 
      <row>
@@ -81,7 +81,7 @@
      <row>
       <entry>libpqxx</entry>
       <entry>C++</entry>
-      <entry>Interface C++, nouveau style</entry>
+      <entry>Interface C++</entry>
       <entry><ulink url="http://pqxx.org/">http://pqxx.org/</ulink></entry>
      </row>
 

postgresql/func.xml

@@ -11170,16 +11170,31 @@ transformation-table2
 
            <note>
             <para>
-             Dans <function>json_populate_record</function>,
+             Bien que les exemples des fonctions
+             <function>json_populate_record</function>,
              <function>json_populate_recordset</function>,
              <function>json_to_record</function> et
-             <function>json_to_recordset</function>, la coercion de type à partir de
-             JSON est fait sur le principe du <quote>meilleur effort</quote> et pourrait
-             ne pas résulter en les valeurs souhaitées pour certains types. Les clés
-             JSON sont comparées aux colonnes de même nom dans le type row cible. Les
-             champs JSON qui n'apparaissent pas dans le type row cible seront omis de
-             la sortie, et les colonnes cibles qui ne correspondent à aucun champ JSON
-             auront simplement pour valeur NULL.
+             <function>json_to_recordset</function> utilisent des constantes,
+             l'utilisation typique sera de référencer une table dans la clause
+             <literal>FROM</literal> et d'utiliser une de ces colonnes
+             <type>json</type> ou <type>jsonb</type> comme argument de la
+             fonction. Les valeurs extraites des clés peuvent ensuite être
+             référencées dans d'autres parties de la requête, comme les
+             clauses <literal>WHERE</literal> et les listes cibles. Extraire
+             plusieurs valeurs de cette façon peut améliorer les performances
+             par rapport à les extraire séparément avec les opérateurs par
+             clé.
+            </para>
+
+            <para>
+             Les clés JSON keys sont vérifiées pour une correspondance avec
+             des noms identiques de colonnes dans le type ligne cible. La
+             coercion du type JSON pour ces requêtes est fait <quote>au
+             mieux</quote> et pourrait résulter en des valeurs non désirées
+             pour certains types. Les champs JSON qui n'apparaissent pas dans
+             le type de ligne cible seront omis de la sortie, et les colonnes
+             cibles qui ne correspondent pas à un champ JSON seront simplement
+             NULL.
             </para>
            </note>
 

postgresql/high-availability.xml

@@ -1413,7 +1413,7 @@ primary_slot_name = 'node_a_slot'
    demanderait un fichier de l'archive WAL, en retournant un échec si le
    fichier n'était pas disponible. Pour un fonctionnement en standby, il est normal que
    le prochain fichier WAL ne soit pas disponible, ce qui entraîne que le standby doive attendre
-   qu'il apparaisse. Pour les fichiers se terminant en <literal>.backup</literal> ou
+   qu'il apparaisse. Pour les fichiers se terminant en
    <literal>.history</literal> il n'y a pas besoin d'attendre, et un code retour
    différent de zéro doit être retourné. Une <varname>restore_command</varname>  d'attente
    peut être écrite comme un script qui boucle après avoir scruté l'existence du prochain fichier de WAL.

postgresql/install-windows.xml

@@ -513,7 +513,7 @@
       dans la bibliothèque ActiveState Perl Package Manager (PPM). Pour
       installer, téléchargez l'archive source <filename>IPC-
       Run-&lt;version&gt;.tar.gz</filename> à partir de CPAN, sur <ulink
-      url="http://search.cpan.org/dist/IPC-Run/"></ulink>, et décompressez-la.
+      url="https://metacpan.org/release/IPC-Run/"></ulink>, et décompressez-la.
       Modifiez le fichier <filename>buildenv.pl</filename>, et ajoutez une
       variable PERL5LIB pour pointer vers le sous-répertoire
       <filename>lib</filename> à partir de l'archive extraite. Par

postgresql/libpq.xml

@@ -7404,7 +7404,7 @@ main(int argc, char **argv)
     /* Set always-secure search path, so malicous users can't take control. */
     res = PQexec(conn,
                  "SELECT pg_catalog.set_config('search_path', '', false)");
-    if (PQresultStatus(res) != PGRES_COMMAND_OK)
+    if (PQresultStatus(res) != PGRES_TUPLES_OK)
     {
         fprintf(stderr, "SET failed: %s", PQerrorMessage(conn));
         PQclear(res);
@@ -7575,7 +7575,7 @@ main(int argc, char **argv)
     /* Set always-secure search path, so malicous users can't take control. */
     res = PQexec(conn,
                  "SELECT pg_catalog.set_config('search_path', '', false)");
-    if (PQresultStatus(res) != PGRES_COMMAND_OK)
+    if (PQresultStatus(res) != PGRES_TUPLES_OK)
     {
         fprintf(stderr, "SET failed: %s", PQerrorMessage(conn));
         PQclear(res);

postgresql/lobj.xml

@@ -896,7 +896,7 @@ main(int argc, char **argv)
      */
     res = PQexec(conn,
                  "SELECT pg_catalog.set_config('search_path', '', false)");
-    if (PQresultStatus(res) != PGRES_COMMAND_OK)
+    if (PQresultStatus(res) != PGRES_TUPLES_OK)
     {
         fprintf(stderr, "SET failed: %s", PQerrorMessage(conn));
         PQclear(res);

postgresql/ltree.xml

@@ -501,18 +501,16 @@ foo         <lineannotation>Correspond au chemin exact <literal>foo</literal></l
      <row>
       <entry><function>lca(ltree, ltree, ...)</function><indexterm><primary>lca</primary></indexterm></entry>
       <entry><type>ltree</type></entry>
-      <entry>plus petit ancêtre commun, c'est-à-dire préfixe commun le plus
-       long des chemins (jusqu'à huit arguments supportés)</entry>
-      <entry><literal>lca('1.2.2.3','1.2.3.4.5.6')</literal></entry>
+      <entry>plus long ancêtre commun de chemins (jusqu'à huit arguments supportés)</entry>
+      <entry><literal>lca('1.2.3','1.2.3.4.5.6')</literal></entry>
       <entry><literal>1.2</literal></entry>
      </row>
 
      <row>
       <entry><function>lca(ltree[])</function></entry>
       <entry><type>ltree</type></entry>
-      <entry>plus petit ancêtre commun, c'est-à-dire préfixe commun le plus
-       long des chemins</entry>
-      <entry><literal>lca(array['1.2.2.3'::ltree,'1.2.3'])</literal></entry>
+      <entry>plus long ancêtre commun de chemins dans le tableau</entry>
+      <entry><literal>lca(array['1.2.3'::ltree,'1.2.3.4'])</literal></entry>
       <entry><literal>1.2</literal></entry>
      </row>
 

postgresql/pgcrypto.xml

@@ -65,7 +65,7 @@
 
    <synopsis>
     hmac(data text, key text, type text) returns bytea
-    hmac(data bytea, key text, type text) returns bytea
+    hmac(data bytea, key bytea, type text) returns bytea
    </synopsis>
 
    <para>