Corrections sur ddl.xml

postgresql/ddl.xml

@@ -1280,7 +1280,7 @@ ALTER TABLE produits ADD FOREIGN KEY (id_groupe_produit) REFERENCES groupes_prod
 <programlisting>ALTER TABLE produits DROP CONSTRAINT un_nom;</programlisting>
     (Dans le cas d'un nom de contrainte généré par le système, comme
     <literal>$2</literal>, il est nécessaire de l'entourer de guillemets doubles
-    (<literal>&quot;</literal>)pour en faire un identifiant valable.)
+    (<literal>&quot;</literal>) pour en faire un identifiant valable.)
    </para>
 
    <para>
@@ -1433,7 +1433,7 @@ ALTER TABLE produits ADD FOREIGN KEY (id_groupe_produit) REFERENCES groupes_prod
 
   <para>
    Un objet peut se voir affecter un nouveau propriétaire avec la commande
-   <command>ALTER</command> correspondante à l'objet, par exemple <xref
+   <command>ALTER</command> correspondant à l'objet, par exemple <xref
    linkend="sql-altertable"/>. Les superutilisateurs peuvent toujours le
    faire. Les rôles ordinaires peuvent seulement le faire s'ils sont le
    propriétaire actuel de l'objet (ou un membre du rôle propriétaire) et un
@@ -1852,7 +1852,7 @@ UPDATE 0
    ligne pour s'assurer que l'intégrité des données est maintenue. Une
    attention particulière doit être prise lors de la mise en place des
    schémas et des politiques de sécurité de niveau ligne pour éviter qu'un
-   cannal caché (<literal>covert channel</literal>) ne dévoile des informations
+   canal caché (<literal>covert channel</literal>) ne dévoile des informations
    à travers de telles vérifications d'intégrité référentielle.
   </para>
 
@@ -2671,7 +2671,7 @@ VALUES ('Albany', NULL, NULL, 'NY');</programlisting>
    <command>INSERT</command> insère toujours dans la table indiquée. Dans
    certains cas, il est possible de rediriger l'insertion en utilisant une
    règle (voir <xref linkend="rules"/>). Néanmoins, cela n'est d'aucune aide
-   dans le cas ci-dessus, car la table <structname>villes</structname> ne 
+   dans le cas ci-dessus, car la table <structname>villes</structname> ne
    contient pas la colonne <structfield>etat</structfield>. La commande est donc
    rejetée avant que la règle ne puisse être appliquée.
   </para>
@@ -3403,7 +3403,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
 
      <listitem>
       <para>
-       Lorsqu'un <command>UPDATE</command> fait déplace une ligne d'une partition
+       Lorsqu'un <command>UPDATE</command> fait déplacer une ligne d'une partition
        à une autre, il y a un risque qu'un autre <command>UPDATE</command> ou
        <command>DELETE</command> simultanée rate cette ligne.
        Supposons que la session 1 effectue un <command>UPDATE</command> sur une
@@ -3413,7 +3413,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
        cette ligne si elle est supprimée de la partition en raison de l'activité
        de la session 1. Dans ce cas, l'<command>UPDATE</command> ou le
        <command>DELETE</command> de la session 2, ignorant le déplacement de la
-       ligne, pense que celle-ci vient d'être supprimée et conclus qu'il n'y a
+       ligne, pense que celle-ci vient d'être supprimée et conclut qu'il n'y a
        rien à faire pour elle. Dans le cas où la table n'est pas partitionnée,
        ou dans le cas où il n'y a pas de déplacement de ligne, la session 2
        aurait identifié la ligne nouvellement mise à jour et aurait donc
@@ -3424,9 +3424,9 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
 
      <listitem>
       <para>
-          <literal>BEFORE ROW</literal> déclencheurs (<literal>triggers</literal>),
-          si nécessaire, il doit être définie sur des partitions individuelles,
-          et non sur la table partitionnée.
+       en cas de besoin, les triggers <literal>BEFORE ROW</literal> doivent
+       être définies sur des partitions individuelles, et non sur la table
+       partitionnée.
       </para>
      </listitem>
 
@@ -3437,7 +3437,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
        table partitionnée est permanente, ses partitions doivent l'être aussi&nbsp;;
        de même si la table partitionnée est temporaire, ses partitions doivent
        l'être aussi. Lors de l'utilisation de relations temporaires, tous les
-       membres de l'arborescence des partitions doivent être issue de la même
+       membres de l'arborescence des partitions doivent être issus de la même
        session.
       </para>
      </listitem>
@@ -3474,7 +3474,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
 
       <listitem>
        <para>
-        e partitionnement déclaratif ne prend en charge que le partitionnement
+        Le partitionnement déclaratif ne prend en charge que le partitionnement
         par intervalle, par liste et par hachage, tandis que l'héritage de table
         permet de diviser les données de la manière choisie par l'utilisateur.
         (Notez, cependant, que si l'exclusion de contrainte n'est pas en mesure
@@ -3868,7 +3868,7 @@ ANALYZE mesure;
   </sect2>
 
   <sect2 id="ddl-partition-pruning">
-   <title>Elagage de partition</title>
+   <title>Élagage de partition</title>
 
  <indexterm>
   <primary>élagage de partition</primary>
@@ -3887,7 +3887,7 @@ SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';</programli
   partitions de la table <structname>mesure</structname>. Avec l'élagage de
   partition activé, le planificateur examinera la définition de chaque partition
   et montrera qu'il n'est pas nécessaire de la parcourir car elle ne contient
-  aucune ligne respectant la clause WHERE (où) de la requête. Lorsque le
+  aucune ligne respectant la clause WHERE de la requête. Lorsque le
   planificateur peut le confirmer, il exclut (élague) la partition du plan de recherche.
 
  </para>
@@ -3896,7 +3896,7 @@ SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';</programli
     En utilisant la commande <command>EXPLAIN</command> et le paramètre de
     configuration <xref linkend="guc-enable-partition-pruning"/>, il est possible
     de voir la différence entre un plan pour lequel des partitions ont été
-    élaguées et ce pour lequel elles ne l'ont pas été. Un plan typique non
+    élaguées et celui pour lequel elles ne l'ont pas été. Un plan typique non
     optimisé pour ce type de configuration de table serait&nbsp;:
 
 <programlisting>SET enable_partition_pruning = off;
@@ -3950,19 +3950,19 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
    <para>
     L'élagage des partitions peut être effectuée non seulement lors de la
     planification d'une requête, mais aussi lors de son exécution. Ceci est
-    utile car cela peut permettre d'élager plus de partitions lorsque les
+    utile car cela peut permettre d'élaguer plus de partitions lorsque les
     clauses contiennent des expressions dont les valeurs ne sont pas connues
     au moment de la planification de la requête&nbsp;; par exemple, des paramètres
     définis dans une instruction <command>PREPARE</command>, utilisant une
     valeur obtenue d'une sous-requête ou utilisant une valeur paramétrée sur
     la partie interne du n&oelig;ud de boucle imbriqué (<literal>nested loop join</literal>.
     L'élagage de la partition pendant l'exécution peut être réalisé à l'un des
-    moments suivant&nbsp;: 
-    
+    moments suivant&nbsp;:
+
     <itemizedlist>
      <listitem>
       <para>
-       Lors de l'initialisation du plan d'execution, l'élagage de partition peut
+       Lors de l'initialisation du plan d'exécution, l'élagage de partition peut
        être effectué pour les valeurs de paramètres qui sont connues pendant
        cette phase. Les partitions qui ont été élaguées pendant cette étape
        n'apparaîtront pas dans l'<command>EXPLAIN</command> ou l'<command>EXPLAIN
@@ -3975,7 +3975,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
 
      <listitem>
       <para>
-       Pendant exécution réelle du plan d'exécution. L'élagage des partitions
+       Pendant l'exécution réelle du plan d'exécution. L'élagage des partitions
        peut également être effectué pour supprimer des partitions en utilisant
        des valeurs qui ne sont connues que pendant l'exécution de la requête.
        Cela inclut les valeurs des sous-requêtes et les valeurs utilisées
@@ -3984,7 +3984,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
        Comme la valeur de ces paramètres peut changer plusieurs fois pendant
        l'exécution de la requête, l'élagage de la partition est effectué chaque
        fois que l'un des paramètres d'exécution utilisés pour celui-ci change.
-       Déterminer si les partitions ont été élagagé pendant cette phase nécessite
+       Déterminer si les partitions ont été élaguées pendant cette phase nécessite
        une inspection minutieuse de la propriété <literal>nloops</literal> de la
        sortie d'<command>EXPLAIN ANALYZE</command>.
       </para>
@@ -4029,33 +4029,32 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
    </indexterm>
 
    <para>
-    Les <firstterm>contraintes d'exclusion</firstterm> est une technique
+    Les <firstterm>contraintes d'exclusion</firstterm> sont une technique
     d'optimisation de requêtes similaire à l'élagage de partitions. Bien qu'il
     soit principalement utilisé pour les tables partitionnées à l'aide de la
     méthode par héritage, il peut être utilisé à d'autres fins, y compris avec
     le partitionnement déclaratif.
    </para>
 
    <para>
-    Les contraintes d'exclusion fonctionne d'une manière très similaire à
+    Les contraintes d'exclusion fonctionnent d'une manière très similaire à
     l'élagage de partitions, sauf qu'elle utilise les contraintes
     <literal>CHECK</literal> de chaque table (d'où son nom) alors que l'élagage
     de partition utilise les limites de partition de la table, qui n'existe que
     dans le cas d'un partitionnement déclaratif. Une autre différence est que
-    la contrainte d'exclusion n'est appliquée qu'au moment de la plannification
+    la contrainte d'exclusion n'est appliquée qu'au moment de la planification
     du plan d'excution&nbsp;; il n'y a donc pas de tentative de suppression de
     partitions au moment de l'exécution.
    </para>
 
    <para>
-    Du fait que les contraintes d'exclusion utilises la contrainte
+    Du fait que les contraintes d'exclusion utilisent la contrainte
     <literal>CHECK</literal>, ceci la rend plus lente par rapport à l'élagage
     de partitions. Néamoins, il peut parfois être utilisé comme un avantage&nbsp;:
     puisque les contraintes peuvent être définies même sur des tables avec
-    partitionnement déclarative, en plus de leurs limites internes, les contraintes
-    d'exclusion peuvent être capable de supprimer des partitions supplémentaires
-    pendant la phase de plannification de la requête.
-
+    partitionnement déclaratif, en plus de leurs limites internes, les contraintes
+    d'exclusion peuvent être capables de supprimer des partitions supplémentaires
+    pendant la phase de planification de la requête.
    </para>
 
    <para>
@@ -4075,9 +4074,10 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
   <itemizedlist>
    <listitem>
     <para>
-     Les contraintes d'exclusion ne n'sont appliquées que lors de la phase de
+     Les contraintes d'exclusion ne sont appliquées que lors de la phase de
      planification de la requête&nbsp;; contrairement à l'élagage de partition,
-     elle ne peut pas être appliquée lors de la phase d'exécution de la requête.
+     elles ne peuvent pas être appliquées lors de la phase d'exécution de la
+     requête.
     </para>
    </listitem>