Mise à jour en version 10.9

postgresql/datatype.xml

@@ -2992,36 +2992,37 @@ SELECT EXTRACT(days from '80 hours'::interval);
    </table>
 
    <para>
-    Les libellés valides pour l'état <quote>vrai</quote> sont&nbsp;:
+    Les constantes booléennes peuvent être représentées dans les requêtes SQL
+    avec les mots clés SQL <literal>TRUE</literal>, <literal>FALSE</literal>
+    et <literal>NULL</literal>.
+   </para>
+
+   <para>
+    La fonction en entrée pour le type <type>boolean</type> accepte ces
+    représentations, sous forme de chaîne de caractères, pour l'état
+    <quote>true</quote>&nbsp;:
     <simplelist>
-     <member><literal>TRUE</literal></member>
-     <member><literal>'t'</literal></member>
-     <member><literal>'true'</literal></member>
-     <member><literal>'y'</literal></member>
-     <member><literal>'yes'</literal></member>
-     <member><literal>'on'</literal></member>
-     <member><literal>'1'</literal></member>
+     <member><literal>true</literal></member>
+     <member><literal>yes</literal></member>
+     <member><literal>on</literal></member>
+     <member><literal>1</literal></member>
     </simplelist>
-    Pour l'état <quote>faux</quote>, il s'agit de&nbsp;:
+    et ces représentations pour l'état <quote>false</quote>&nbsp;:
     <simplelist>
-     <member><literal>FALSE</literal></member>
-     <member><literal>'f'</literal></member>
-     <member><literal>'false'</literal></member>
-     <member><literal>'n'</literal></member>
-     <member><literal>'no'</literal></member>
-     <member><literal>'off'</literal></member>
-     <member><literal>'0'</literal></member>
+     <member><literal>false</literal></member>
+     <member><literal>no</literal></member>
+     <member><literal>off</literal></member>
+     <member><literal>0</literal></member>
     </simplelist>
-    Les espaces avant ou après, ainsi que la casse, sont ignorés.
-    Il est recommandé d'utiliser <literal>TRUE</literal> et
-    <literal>FALSE</literal> (qui sont compatibles avec la norme
-    <acronym>SQL</acronym>).
+    Les préfixes uniques de ces chaînes sont aussi acceptés, par exemple
+    <literal>t</literal> ou <literal>n</literal>. Les espaces avant ou après,
+    ainsi que la casse, sont ignorés.
    </para>
 
    <para>
-    L'<xref linkend="datatype-boolean-example"/> montre que
-    les valeurs booléennes sont affichées avec les lettres
-    <literal>t</literal> et <literal>f</literal>.
+    La fonction en sortie pour le <type>boolean</type> renvoie toujours soit
+    <literal>t</literal> soit <literal>f</literal>, comme indiqué dans <xref
+    linkend="datatype-boolean-example"/>.
    </para>
 
    <example id="datatype-boolean-example">
@@ -3041,6 +3042,28 @@ SELECT * FROM test1 WHERE a;
 ---+---------
  t | sic est</programlisting>
    </example>
+
+   <para>
+    Les mots clés <literal>TRUE</literal> et <literal>FALSE</literal> sont la
+    méthode préférée (compatible <acronym>SQL</acronym>) pour l'écriture des
+    constantes booléennes dans les requêtes SQL. Cependant, vous pouvez aussi
+    utiliser les représentations sous forme de chaîne de caractères en suivant
+    la syntaxe générique décrite dans <xref
+    linkend="sql-syntax-constants-generic"/>, par exemple
+    <literal>'yes'::boolean</literal>.
+   </para>
+
+   <para>
+    Notez que l'analyseur comprend automatiquement que <literal>TRUE</literal>
+    et <literal>FALSE</literal> sont du type <type>boolean</type>, mais ce
+    n'est pas le cas pour <literal>NULL</literal> car il peut avoir tout type.
+    Donc, dans certains contextes, vous devrez convertir explicitement
+    <literal>NULL</literal> vers le type <type>boolean</type>, par exemple
+    <literal>NULL::boolean</literal>. À l'inverse, la conversion peut être
+    omise d'une valeur booléenne représentée sous la forme d'une chaîne de
+    caractères dans les contextes où l'analyseur peut déduire que la constante
+    doit être de type <type>boolean</type>.
+   </para>
   </sect1>
 
   <sect1 id="datatype-enum">

postgresql/ddl.xml

@@ -2849,9 +2849,10 @@ VALUES ('Albany', NULL, NULL, 'NY');</programlisting>
       </listitem>
     </itemizedlist>
 
-    Ces déficiences seront probablement corrigées dans une version future,
-    mais, en attendant, il est obligatoire de réfléchir consciencieusement à l'utilité
-    de l'héritage pour une application donnée.
+    Certaines fonctionnalités non implémentées pour les hiérarchies d'héritage
+    sont disponibles pour le partitionnement déclaratif. Il est de ce fait
+    nécessaire de réfléchir consciencieusement à l'utilité de l'héritage pour
+    une application donnée.
   </para>
 
    </sect2>
@@ -3994,6 +3995,92 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
   </itemizedlist>
  </para>
 </sect2>
+
+  <sect2 id="ddl-partitioning-declarative-best-practices">
+   <title>Bonnes pratiques pour le partitionnement déclaratif</title>
+
+   <para>
+    Le choix de la méthode de partitionnement d'une table doit être fait avec
+    beaucoup d'attention car les performances de l'optimisation des requêtes
+    et leur exécution peuvent être fortement affectées négativement par un
+    mauvais design.
+   </para>
+
+   <para>
+    Une des décisions les plus critiques au niveau du design est le choix de
+    la clé (ou des clés) de partitionnement. Souvent, le meilleur choix
+    revient à partitionner par la (ou les) colonne(s) qui apparaissent le plus
+    fréquemment dans les clauses <literal>WHERE</literal> des requêtes en
+    cours d'exécution sur la table partitionnée. Les éléments de la clause
+    <literal>WHERE</literal> qui correspondent ou sont compatibles avec la clé
+    de partitionnement peuvent être utilisés pour ignorer les partitions
+    inutiles. La suppression des données inutiles est aussi un facteur à
+    considérer lors de la conception de votre stratégie de partitionnement.
+    Une partition entière peut être détachée rapidement, donc il peut être
+    bénéfique de concevoir la stratégie de partitionnement d'une telle façon
+    que tout les données à supprimer d'un coup soient concentrées sur une
+    seule partition.
+   </para>
+
+   <para>
+    Choisir le nombre cible de partitions pour la table est aussi une décision
+    critique à prendre. Ne pas avoir suffisamment de partitions pourrait avoir
+    pour conséquence des index trop gros, et un emplacement des données pauvre
+    qui résulterait en un ratio bas de lecture en cache. Néanmoins, diviser la
+    table en trop de partitions pourrait aussi causer des problèmes. Trop de
+    partitions pourrait signifier une optimisation plus longue des requêtes et
+    une consommation mémoire plus importante durant l'optimisation et
+    l'exécution. Lors de la conception du partitionnement de votre table, il
+    est aussi important de prendre compte les changements pouvant survenir
+    dans le futur. Par exemple, si vous choisissez d'avoir une partition par
+    client et que vous avez un petit nombre de gros clients, il est important
+    de réfléchir aux implications si, dans quelques années, vous vous trouvez
+    avec un grand nombre de petits clients. Dans ce cas, il serait mieux de
+    choisir de partitionner par <literal>RANGE</literal> et de choisir un
+    nombre raisonnable de partitions, chacune contenant un nombre fixe de
+    clients, plutôt que d'essayer de partitionner par <literal>LIST</literal>
+    en espérant que le nombre de clients ne dépasse pas ce qui est possible au
+    niveau du partitionnement des données.
+   </para>
+
+   <para>
+    Le sous-partitionnement peut aussi être utile pour diviser encore plus
+    les partitions pour lesquelles on s'attend à ce qu'elles deviennent bien
+    plus grosses que les autres partitions. Un sous-partitionnement excessif
+    peut facilement amener à un grand nombre de partitions et peut causer les
+    problèmes mentionnés dans le paragraphe précédent.
+   </para>
+
+   <para>
+    Il est aussi important de considérer la surcharge du partitionnement lors
+    de l'optimisation et de l'exécution. L'optimiseur est généralement capble
+    de gérer les hiérarchies de partitions qui montent à quelques centaines de
+    partitions. Les durées d'optimisation deviennent plus longues et la
+    consommation de mémoire devient plus importante au fur et à mesure de
+    l'ajout de partitions. Ceci est tout particulièrement vrai pour les
+    commandes <command>UPDATE</command> et <command>DELETE</command>. Une
+    autre raison de se soucier d'un grand nombre de partitions est que la
+    consommation mémoire du serveur pourrait grossir de façon significative
+    sur une période de temps, et tout spécialement si beaucoup de sessions
+    touchent un grand nombre de partitions. Ceci est dû au chargement des
+    métadonnées nécessaires pour chaque partition en mémoire locale.
+   </para>
+
+   <para>
+    Avec une charge de type entrepôt de données, il peut être sensé d'utiliser
+    un plus grand nombre de partitions que pour une charge de type
+    <acronym>OLTP</acronym>. En général, dans les entrepôts de données, le
+    temps d'optimisation d'une requête est peu importante parce que la
+    majorité du temps de traitement est passée sur l'exécution de la requête.
+    Avec l'une de ces deux types de charges, il est important de prendre les
+    bonnes décisions dès le début, car le re-partitionnement de grosses
+    quantités de données peut être très lent. Les simulations de la charge
+    attendue sont souvent bénéfiques pour optimiser la stratégie de
+    partitionnement. Ne jamais supposer qu'un plus grand nombre de partitions
+    est toujours mieux qu'un petit nombre de partitions, et vice-versa.
+   </para>
+  </sect2>
+
 </sect1>
 
 <sect1 id="ddl-foreign-data">

postgresql/func.xml

@@ -12218,31 +12218,74 @@ transformation-table2
 
            <note>
             <para>
-             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> 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
+             Les fonctions <function>json[b]_populate_record</function>,
+             <function>json[b]_populate_recordset</function>,
+             <function>json[b]_to_record</function> et
+             <function>json[b]_to_recordset</function> opèrent sur un objet
+             JSON ou un tableau d'objets, et extraient les valeurs associées
+             aux clés dont le nom correspond au nom des clonnes dans le type
+             de ligne en sortie. Les champs de l'objet qui ne correspondent
+             pas à un nom de colonne en sortie sont ignorés, et les colonnes
+             en sortie qui ne correspondent pas à un champ de l'objet seront à
+             NULL. Pour convertir une valeur JSON vers le type SQL d'une
+             colonne en sortie, les règles suivantes sont appliquées
+             séquentiellement&nbsp;:
+             <itemizedlist spacing="compact">
+              <listitem>
+               <para>
+                Une valeur JSON null est convertie en un NULL SQL dans tous
+                les cas.
+               </para>
+              </listitem>
+              <listitem>
+               <para>
+                Si la colonne en sortie est de type <type>json</type> ou
+                <type>jsonb</type>, la valeur JSON est reproduite exactement.
+               </para>
+              </listitem>
+              <listitem>
+               <para>
+                Si la colonne en sortie est de type composite (ligne), et que
+                la valeur JSON est un objet JSON, les champs de l'objets sont
+                convertis en colonnes du type de ligne en sortie par
+                application récursive de ces règles.
+               </para>
+              </listitem>
+              <listitem>
+               <para>
+                De la même façon, si la colonne en sortie est un type tableau
+                et que la valeur JSON est un tableau JSON, les éléments du
+                tableau JSON sont convertis en éléments du tableau en sortie
+                par application récursive de ces règles.
+               </para>
+              </listitem>
+              <listitem>
+               <para>
+                Sinon, si la valeur JSON est une chaîne constante, le contenu
+                de la chaîne est envoyée à la fonction de conversion en entrée
+                pour le type de données de la colonne.
+               </para>
+              </listitem>
+              <listitem>
+               <para>
+                Sinon, la représentation textuelle de la valeur JSON est
+                envoyée à la fonction de conversion en entrée pour le type de
+                données de la colonne.
+               </para>
+              </listitem>
+             </itemizedlist>
+            </para>
+
+            <para>
+             Bien que les exemples pour ces fonctions utilisent des
+             constantes, l'utilisation typique est de référencer une table
+             dans la clause <literal>FROM</literal> et d'utiliser une de ses
+             colonnes <type>json</type> ou <type>jsonb</type> comme argument
+             de la fonction. Les valeurs clés extraites 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.
+             sur leur extraction séparée avec des opérateurs par clé.
             </para>
            </note>
 
@@ -19611,9 +19654,11 @@ off
     Voir <xref linkend="streaming-replication"/>,
     <xref linkend="streaming-replication-slots"/>, et
     <xref linkend="replication-origins"/>
-    pour des informations sur les fonctionnalités
-    sous-jacentes. L'utilisation de ces fonctions est restreinte aux
-    superutilisateurs.
+    pour des informations sur les fonctionnalités sous-jacentes. L'utilisation
+    des fonctions sur l'origine de la réplication est restreinte aux
+    superutilisateurs. L'utilisation des fonctions sur les slots de
+    réplication est restreinte aux superutilisateurs et aux utilisateurs ayant
+    l'attribut <literal>REPLICATION</literal>.
    </para>
 
    <para>

postgresql/information_schema.xml

@@ -7010,8 +7010,11 @@ ORDER BY c.ordinal_position;
      <row>
       <entry><literal>check_option</literal></entry>
       <entry><type>character_data</type></entry>
-      <entry>S'applique à une fonctionnalité non disponible dans
-       <productname>PostgreSQL</productname>.</entry>
+      <entry>
+       <literal>CASCADED</literal> ou <literal>LOCAL</literal> si la vue est
+       définie avec l'option <literal>CHECK OPTION</literal>,
+       <literal>NONE</literal> dans le cas contraire
+      </entry>
      </row>
 
      <row>

postgresql/pgtrgm.xml

@@ -270,6 +270,24 @@
       </para>
      </listitem>
     </varlistentry>
+    <varlistentry id="guc-pgtrgm-strict-word-similarity-threshold" xreflabel="pg_trgm.strict_word_similarity_threshold">
+     <term>
+      <varname>pg_trgm.strict_word_similarity_threshold</varname> (<type>real</type>)
+      <indexterm>
+       <primary>
+        paramètre de configuration <varname>pg_trgm.strict_word_similarity_threshold</varname>
+       </primary>
+      </indexterm>
+     </term>
+     <listitem>
+      <para>
+       Configure la limite stricte actuelle de similarité utilisée par les
+       opérateurs <literal>&lt;&lt;%</literal> et
+       <literal>%&gt;&gt;</literal>. La limite doit être comprise entre 0 et 1
+       (la valeur par défaut est 0,5).
+      </para>
+     </listitem>
+    </varlistentry>
   </variablelist>
  </sect2>