Mise à jour en version 11.18

postgresql/acronyms.xml

@@ -323,9 +323,7 @@
     <term><acronym>HOT</acronym></term>
     <listitem>
      <para>
-      <ulink
-      url="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/README.HOT;hb=HEAD">Heap-Only
-       Tuples</ulink>, tuples en mémoire seule
+      <link linkend="storage-hot">Heap-Only Tuples</link>
      </para>
     </listitem>
    </varlistentry>

postgresql/catalogs.xml

@@ -3991,9 +3991,9 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
        Si vrai, les requêtes ne doivent pas utiliser l'index tant que le
        <structfield>xmin</structfield> de cette ligne de
        <structname>pg_index</structname> est en-dessous de leur horizon
-       d'événements <symbol>TransactionXmin</symbol>, car la table peut
-       contenir des chaînes
-       HOT cassées avec des lignes incompatibles qu'elles peuvent voir.
+       d'événements <symbol>TransactionXmin</symbol>, car la table peut contenir
+       des <link linkend="storage-hot">chaînes HOT</link> cassées avec des
+       lignes incompatibles qu'elles peuvent voir.
       </entry>
      </row>
 

postgresql/config.xml

@@ -3608,7 +3608,8 @@ ANY <replaceable class="parameter">nb_sync</replaceable> ( <replaceable class="p
     </indexterm>
     <para>
      Indique le nombre de transactions pour lesquelles <command>VACUUM</command>
-     et les mises à jour <acronym>HOT</acronym> vont différer le nettoyage des
+     et les <link linkend="storage-hot">mises à jour
+     <acronym>HOT</acronym></link> vont différer le nettoyage des
      versions de lignes mortes. La valeur par défaut est de 0 transactions.
      Cela signifie que les versions de lignes mortes peuvent être supprimées
      dès que possible, autrement dit dès qu'elles ne sont plus visibles par
@@ -5636,6 +5637,13 @@ local0.*    /var/log/postgresql
 <sect2 id="runtime-config-logging-what">
  <title>Que tracer</title>
 
+ <note>
+  <para>
+   Ce que vous choisissez de tracer peut avoir des implications sur la sécurité&nbsp;;
+   voir <xref linkend="logfile-maintenance"/>.
+  </para>
+ </note>
+
  <variablelist>
 
   <varlistentry id="guc-application-name" xreflabel="application_name">
@@ -6086,6 +6094,10 @@ log_line_prefix = '%m [%p] %q%u@%d/%a '
       <varname>log_min_error_statement</varname> doit être positionné à
       <literal>ERROR</literal> pour tracer ce type d'instructions.
      </para>
+     <para>
+      Les requêtes tracées peuvent révéler des données sensibles et même
+      contenir des mots de passe en clair.
+     </para>
     </note>
    </listitem>
   </varlistentry>

postgresql/datatype.xml

@@ -1145,6 +1145,8 @@ SELECT '52093.89'::money::numeric::float8;
     <type>char(<replaceable>n</replaceable>)</type> sont des alias de
     <type>character varying(<replaceable>n</replaceable>)</type> et
     <type>character(<replaceable>n</replaceable>)</type>, respectivement.
+    Si indiqué, la longueur doit être supérieure à zéro et ne peut pas
+    excéder 10485760.
     <type>character</type> sans indication de taille est équivalent à
     <type>character(1)</type>. Si <type>character varying</type> est
     utilisé sans indicateur de taille, le type accepte des chaînes de

postgresql/ddl.xml

@@ -3471,13 +3471,14 @@ ALTER INDEX measurement_city_id_logdate_key
     <itemizedlist>
      <listitem>
       <para>
-       Les contraintes d'unicité (et de ce fait les clés primaires) sur des
-       tables partitionnées doivent inclure toutes les colonnes faisant partie
-       de la clé de partitionnement. Cette limitation existe parce que les
-       index individuels créant la contrainte peuvent seulement forcés
-       l'unicité sur leur propre partition&nbsp;; de ce fait, la structure
-       même de la partition doit garantir qu'il n'existe pas de duplicats dans
-       les différentes partitions.
+       Pour créer une contrainte d'unicité ou de clé primaire sur une table
+       partitionnée, la clé de partitionnement ne doit pas inclure d'expressions
+       ou d'appels de fonction, et les colonnes de la contrainte doivent inclure
+       toutes les colonnes de la clé de partitionnement. Cette limitation existe
+       parce que les index individuels forçant la contrainte peuvent seulement
+       garantir l'unicité dans leur propre partition&nbsp;; de ce fait, la
+       structure même de la partition doit garantir qu'il n'y aura pas de
+       duplicats dans les différentes partitions.
       </para>
      </listitem>
 

postgresql/docguide.xml

@@ -65,7 +65,7 @@
    lecture en ligne. Le <ulink
    url="http://newbiedoc.sourceforge.net/metadoc/docbook-guide.html">guide
     DocBook des nouveaux venus</ulink> est très utile pour les débutants. Le
-   <ulink url="https://www.freebsd.org/docproj/docproj.html">projet de
+   <ulink url="https://www.freebsd.org/docproj/">projet de
     documentation FreeBSD</ulink> utilise également DocBook et fournit
    également de bonnes informations, incluant un certain nombre de
    lignes directrices qu'il peut être bon de prendre en considération.

postgresql/func.xml

@@ -11735,7 +11735,12 @@ transformation-table2
    linkend="functions-comparison-op-table"/> sont disponibles pour le type
    <type>jsonb</type>, mais pas pour le type <type>json</type>. Ils suivent les
    règles de tri des opérations B-tree soulignées dans <xref
-   linkend="json-indexing"/>.
+   linkend="json-indexing"/>.  Voir aussi <xref linkend="functions-aggregate"/>
+   pour la fonction d'agrégat <function>json_agg</function> qui agrège les
+   valeurs d'enregistrement sous la forme d'un document JSON, la fonction
+   d'agrégat <function>json_object_agg</function> qui agrège les paires de
+   valeurs dans un objet JSON, et leurs équivalents <type>jsonb</type>, à savoir
+   <function>jsonb_agg</function> et <function>jsonb_object_agg</function>.
   </para>
   <para>
    Des opérateurs supplémentaires existent seulement pour le type
@@ -12600,15 +12605,6 @@ transformation-table2
         <type>jsonb</type> n'ont jamais des noms de champs dupliqués.
        </para>
       </note>
-
-      <para>
-       Voir aussi <xref linkend="functions-aggregate"/> pour la fonction d'agrégat
-       <function>json_agg</function> qui agrège les valeurs en tant que JSON, et
-       la fonction d'agrégat <function>json_object_agg</function> qui agrège les
-       paires de valeurs en un objet JSON, et leurs équivalents <type>jsonb</type>,
-       <function>jsonb_agg</function> et <function>jsonb_object_agg</function>.
-      </para>
-
      </sect1>
 
      <sect1 id="functions-sequence">

postgresql/indexam.xml

@@ -39,7 +39,8 @@
   est un objet indépendant qui a besoin de sa propre entrée. En conséquence,
   la mise à jour d'une ligne crée toujours de nouvelles entrées
   dans l'index pour cette ligne, même si les valeurs de la clé ne changent pas.
-  (Les lignes HOT sont une exception ; mais les index ne s'en occupent pas).
+  (Les <link linkend="storage-hot">lignes HOT</link>
+  sont une exception&nbsp;; mais les index ne s'en occupent pas).
   Les entrées d'index pour les lignes mortes sont nettoyées (par
   le VACUUM) lorsque les lignes mortes elles-même sont nettoyées.
  </para>

postgresql/indices.xml

@@ -103,19 +103,21 @@
 
   <para>
    Après la création d'un index, le système doit le maintenir synchronisé avec
-   la table. Cela rend plus lourdes les opérations de manipulation de
-   données. C'est pourquoi les index qui sont peu, voire jamais, utilisés
-   doivent être supprimés.
+   la table. Cela rend plus lourdes les opérations de manipulation de données.
+   Les index peuvent aussi empêcher la création des <link
+   linkend="storage-hot">heap-only tuples</link>. C'est pourquoi les index qui
+   sont peu, voire jamais, utilisés doivent être supprimés.
   </para>
  </sect1>
 
-
  <sect1 id="indexes-types">
   <title>Types d'index</title>
 
   <para>
    <productname>PostgreSQL</productname> propose plusieurs types d'index&nbsp;:
-   B-tree, Hash, GiST, SP-GiST, GIN et BRIN. Chaque type d'index utilise un algorithme
+   B-tree, Hash, GiST, SP-GiST, GIN, BRIN et l'extension <link
+   linkend="bloom">bloom</link>.
+   Chaque type d'index utilise un algorithme
    différent qui convient à un type particulier de requêtes. Par défaut, la
    commande <command>CREATE INDEX</command> crée un index B-tree, ce qui
    convient dans la plupart des situations.
@@ -735,14 +737,14 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
 
   <para>
    Les expressions d'index sont relativement coûteuses à calculer car
-   l'expression doit être recalculée à chaque insertion ou mise à jour (non HOT) de
-   ligne. Néanmoins, les expressions d'index ne sont
-   <emphasis>pas</emphasis> recalculées lors d'une recherche par index car elles sont
-   déjà stockés dans l'index. Dans les deux exemples ci-dessus, le système
-   voit la requête comme un <literal>WHERE colonne_indexée =
-   'constante'</literal>. De ce fait, la recherche est aussi rapide que toute
-   autre requête d'index. Ainsi, les index d'expressions sont utiles
-   lorsque la rapidité de recherche est plus importante que la rapidité
+   l'expression doit être recalculée à chaque insertion ou <link
+   linkend="storage-hot">mise à jour non-HOT</link> de ligne. Néanmoins, les
+   expressions d'index ne sont <emphasis>pas</emphasis> recalculées lors d'une
+   recherche par index car elles sont déjà stockés dans l'index. Dans les deux
+   exemples ci-dessus, le système voit la requête comme un <literal>WHERE
+   colonne_indexée = 'constante'</literal>. De ce fait, la recherche est aussi
+   rapide que toute autre requête d'index. Ainsi, les index d'expressions sont
+   utiles lorsque la rapidité de recherche est plus importante que la rapidité
    d'insertion et de mise à jour.
   </para>
  </sect1>

postgresql/install-windows.xml

@@ -125,7 +125,7 @@
   </para>
 
   <para>
-   Avant de lancer la construction, vous aurez besoin d'éditer le fichier
+   Avant de lancer la construction, vous pouvez créer le fichier
    <filename>config.pl</filename> pour y modifier toutes les options de
    configuration nécessaires, ainsi que les chemins utilisés par les
    bibliothèques de tierces parties. La configuration complète est déterminée

postgresql/installation.xml

@@ -954,7 +954,7 @@ su - postgres
        <listitem>
         <para>
          <option>bsd</option> pour utiliser les fonctions UUID trouvées dans
-         FreeBSD, NetBSD et quelques autres systèmes dérivés de BSD
+         FreeBSD et quelques autres systèmes dérivés de BSD
         </para>
        </listitem>
        <listitem>

postgresql/libpq.xml

@@ -2246,10 +2246,8 @@ const char *PQsslAttribute(const PGconn *conn, const char *attribute_name);
          <term><literal>compression</literal></term>
          <listitem>
           <para>
-           Si la compression SSL est utilisée, renvoie le nom de
-           l'algorithme de compression, ou "on" si la compression est
-           utilisée mais que l'algorithme est inconnu. Si la compression
-           n'est pas utilisée, renvoie "off".
+           Renvoie <literal>on</literal> si la compression SSL est en cours
+           d'utilisation. Renvoie <literal>off</literal> dans le cas contraire.
           </para>
          </listitem>
         </varlistentry>

postgresql/maintenance.xml

@@ -997,9 +997,29 @@ HINT:  Stop the postmaster and vacuum that database in single-user mode.
 
   <para>
    Sauvegarder les journaux de trace du serveur de bases de données dans un
-   fichier plutôt que dans <filename>/dev/NULL</filename> est une bonne idée. Les
+   fichier plutôt que dans <filename>/dev/null</filename> est une bonne idée. Les
    journaux sont d'une utilité incomparable lorsqu'arrive le moment où des
-   problèmes surviennent. Néanmoins, les journaux ont tendance à être
+   problèmes surviennent.
+  </para>
+
+  <note>
+   <para>
+    Les traces d'un serveur peuvent contenir des informations sensibles et ont
+    besoin d'être protégées, peu importe où et comment ils sont enregistrés, ou
+    leur destination d'envoi. Par exemple, certaines requêtes DDL pourraient
+    contenir des mots de passe en clair ou d'autres détails d'authentification.
+    Les instructions tracées au niveau <literal>ERROR</literal> pourraient
+    afficher le code source SQL des applications, et pourraient aussi contenir
+    une partie des lignes de données. Enregistrer des données, événements et
+    informations relatives est le but assumé de cette fonctionnalité, donc il ne
+    s'agit pas d'une fuite d'information ou d'un bug. Merci de vous assurer que
+    les traces du serveur sont visibles uniquement par les personnes
+    appropriées.
+   </para>
+  </note>
+
+  <para>
+   Les journaux ont tendance à être
    volumineux (tout spécialement à des niveaux de débogage importants) et vous
    ne voulez pas les sauvegarder indéfiniment. Vous avez besoin de faire une
    <quote>rotation</quote> des journaux pour que les nouveaux journaux sont

postgresql/monitoring.xml

@@ -2838,8 +2838,8 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
       <row>
        <entry><structfield>n_tup_upd</structfield></entry>
        <entry><type>bigint</type></entry>
-       <entry>Nombre de lignes mises à jour (y compris les lignes mises à jour
-        par HOT)</entry>
+       <entry>Nombre de lignes mises à jour (y compris les <link
+        linkend="storage-hot">lignes mises à jour avec HOT</link>)</entry>
       </row>
       <row>
        <entry><structfield>n_tup_del</structfield></entry>
@@ -3399,6 +3399,19 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
     </tgroup>
    </table>
 
+   <warning>
+    <para>
+     Utiliser <function>pg_stat_reset()</function> réinitialise aussi les
+     compteurs que l'autovacuum utilise pour déterminer quand déclencher une
+     opération VACUUM ou une opération ANALYZE. Réinitialiser ces compteurs peut
+     empêcher l'autovacuum de réaliser un travail pourtant nécessaire, ce qui
+     entrainerait comme conséquence une fragmentation des tables ou des
+     statistiques obsolètes sur les données des tables. Un
+     <command>ANALYZE</command> sur la base est recommandé après avoir
+     réinitialisé les statistiques.
+    </para>
+   </warning>
+
    <para>
     <function>pg_stat_get_activity</function>, la fonction sous-jacente de
     la vue <structname>pg_stat_activity</structname>, retourne un ensemble

postgresql/queries.xml

@@ -2116,8 +2116,10 @@ SELECT sum(n) FROM t;</programlisting>
   <note>
    <para>
     Dans son appellation stricte, ce processus est une itération, pas une
-    récursion, mais <literal>RECURSIVE</literal> est la terminologie choisie
-    par le comité de standardisation de SQL.
+    récursion, mais <literal>RECURSIVE</literal> est la terminologie choisie par
+    le comité de standardisation de SQL. Alors que <literal>RECURSIVE</literal>
+    autorise la spécification récursive des requêtes, en interne, ce type de
+    requêtes est évalué itérativement.
    </para>
   </note>
 
@@ -2137,7 +2139,7 @@ SELECT sum(n) FROM t;</programlisting>
 <programlisting>WITH RECURSIVE parties_incluses(sous_partie, partie, quantite) AS (
     SELECT sous_partie, partie, quantite FROM parties WHERE partie = 'notre_produit'
   UNION ALL
-    SELECT p.sous_partie, p.partie, p.quantite
+    SELECT p.sous_partie, p.partie, p.quantite * pr.quantite
     FROM parties_incluses pr, parties p
     WHERE p.partie = pr.sous_partie
   )

postgresql/query.xml

@@ -679,24 +679,25 @@ ORDER BY ville;</programlisting>
     ce qui nous donne une ligne par ville dans le résultat. Chaque résultat
     d'agrégat est calculé avec les lignes de la table correspondant à la ville.
     Nous pouvons filtrer ces lignes groupées en utilisant
-    <literal>HAVING</literal>&nbsp;:
+    <literal>HAVING</literal> et le décompte en sortie en utilisant
+    <literal>FILTER</literal> &nbsp;:
 
-<programlisting>SELECT ville, max(t_basse)
+<programlisting>SELECT ville, max(t_basse), count(*) FILTER (WHERE t_basse &lt; 30)
     FROM temps
     GROUP BY ville
     HAVING max(t_basse) &lt; 40;</programlisting>
 
-<screen>  ville  | max
----------+-----
- Hayward |  37
-(1 row)</screen>
+<screen>  ville  | max | count
+---------+-----+-------
+ Hayward |  37 |     5
+</screen>
 
     ce qui nous donne le même résultat uniquement pour les villes qui ont
     toutes leurs valeurs de  <structfield>t_basse</structfield> en dessous de
     40. Pour finir, si nous nous préoccupons seulement des villes dont le nom
     commence par <quote><literal>S</literal></quote>, nous pouvons faire&nbsp;:
 
-<programlisting>SELECT ville, max(t_basse)
+<programlisting>SELECT ville, max(t_basse), count(*) FILTER (WHERE t_basse &lt; 30)
     FROM temps
     WHERE ville LIKE 'S%' -- <co id="co.tutorial-agg-like"/>
     GROUP BY ville

postgresql/ref/analyze.xml

@@ -218,17 +218,17 @@ ANALYZE [ VERBOSE ] [ <replaceable class="parameter">table_et_colonnes</replacea
   </para>
 
   <para>
-   Si la table en cours d'analyse a un ou plusieurs enfants,
-   <command>ANALYZE</command> récupérera deux fois les statistiques&nbsp;:
-   une fois sur les lignes de la table parent seulement et une deuxième fois
-   sur les lignes de la table parent et de tous ses enfants. Ce deuxième
-   ensemble de statistiques est nécessaire lors de la planification des
-   requêtes qui traversent l'arbre d'héritage complet. Néanmoins, le
-   démon autovacuum ne considérera que les insertions et mises à jour sur la
-   table parent elle-même pour décider du lancement automatique d'un ANALYZE sur cette table. Si des
-   lignes sont rarement insérées ou mises à jour dans cette table, les
-   statistiques d'héritage ne seront à jour que si vous lancez manuellement
-   un <command>ANALYZE</command>.
+   Si la table en cours d'analyse a des enfants, <command>ANALYZE</command>
+   récupère deux ensembles de statistiques&nbsp;: un sur les lignes de la table
+   parent seulement et un autre sur les lignes de la table parent et de tous ses
+   enfants. Ce deuxième ensemble de statistiques est nécessaire lors de la
+   planification des requêtes qui traversent l'arbre d'héritage complet. Les
+   tables enfants ne sont pas analysées individuellement dans ce cas. Néanmoins,
+   le démon autovacuum ne considérera que les insertions et mises à jour sur la
+   table parent elle-même pour décider du lancement automatique d'un ANALYZE sur
+   cette table. Si des lignes sont rarement insérées ou mises à jour dans cette
+   table, les statistiques d'héritage ne seront à jour que si vous lancez
+   manuellement un <command>ANALYZE</command>.
   </para>
 
   <para>
@@ -242,16 +242,6 @@ ANALYZE [ VERBOSE ] [ <replaceable class="parameter">table_et_colonnes</replacea
    garantie d'être vide.
   </para>
 
-  <para>
-   Par contre, si la table en cours d'analyse a des enfants par héritage,
-   <command>ANALYZE</command> récupère les deux ensembles de statistiques&nbsp;:
-   une sur les lignes de la table parent seule, et une autre incluant les lignes
-   de la table parent et des tables filles. Ce deuxième ensemble de statistiques
-   est nécessaire pour planifier des requêtes qui traitent l'arbre d'héritage
-   dans son ensemble. Les tables filles elles-mêmes ne sont pas analysées
-   individuellement dans ce cas.
-  </para>
-
   <para>
    Le démon autovacuum ne traite pas les tables partitionnées, pas plus qu'il ne
    traite les parents en héritage si seules les tables filles sont modifiées.