Les deux fichiers du jour

et quatre autres fichiers que j'ai dû oublier hier :)

postgresql/perform.xml

@@ -1356,30 +1356,33 @@ nd | {"1, 2": 33178, "1, 5": 33178, "2, 5": 27435, "1, 2, 5": 33178}
    </sect3>
 
    <sect3>
-    <title>Multivariate MCV lists</title>
+    <title>Listes multivariées MCV</title>
 
     <para>
-     Another type of statistics stored for each column are most-common value
-     lists.  This allows very accurate estimates for individual columns, but
-     may result in significant misestimates for queries with conditions on
-     multiple columns.
+     Un autre type de statistiques enregistrées pour chaque colonne est les
+     listes des valeurs les plus communes. Ceci permet des estimations très
+     précises pour les colonnes individuelles mais pourrait résulter en des
+     estimations significativement mauvaises pour les requêtes ayant des
+     filtres sur plusieurs colonnes.
     </para>
 
     <para>
-     To improve such estimates, <command>ANALYZE</command> can collect MCV
-     lists on combinations of columns.  Similarly to functional dependencies
-     and n-distinct coefficients, it's impractical to do this for every
-     possible column grouping.  Even more so in this case, as the MCV list
-     (unlike functional dependencies and n-distinct coefficients) does store
-     the common column values.  So data is collected only for those groups
-     of columns appearing together in a statistics object defined with the
-     <literal>mcv</literal> option.
+     Pour améliorer ces estimations, <command>ANALYZE</command> peut récupérer
+     des listes MCV sur des combinaisons de colonnes. De façon similaire aux
+     dépendances fonctionnelles et coefficients de valeurs distinctes, il
+     n'est pas possible de le faire pour chaque regroupement de colonnes. Ceci
+     est encore plus vrai dans ce cas car la liste MCV (contrairement aux
+     dépendances fonctionnelles et coefficients de valeurs distinctes),
+     enregistre les valeurs les plus communes. Donc les données ne sont
+     récupérées que pour les groupes de colonnes apparaissant dans un objet
+     statistique défini avec l'option <literal>mcv</literal> option.
     </para>
 
     <para>
-     Continuing the previous example, the MCV list for a table of ZIP codes
-     might look like the following (unlike for simpler types of statistics,
-     a function is required for inspection of MCV contents):
+     En continuant sur l'exemple précédent, la liste MCV pour une table de
+     codes ZIP pourrait ressembler à ce qui suit (contrairement aux types plus
+     simples de statistiques, une fonction est requise pour inspecter le
+     contenu du MCV)&nbsp;:
 
 <programlisting>
 CREATE STATISTICS stts3 (mcv) ON state, city FROM zipcodes;
@@ -1404,19 +1407,20 @@ SELECT m.* FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid),
    ...
 (99 rows)
 </programlisting>
-     This indicates that the most common combination of city and state is
-     Washington in DC, with actual frequency (in the sample) about 0.35%.
-     The base frequency of the combination (as computed from the simple
-     per-column frequencies) is only 0.0027%, resulting in two orders of
-     magnitude under-estimates.
+     Ceci indique que la combinaison la plus commune des colonnes city et
+     state est Washington DC, avec la fréquence réelle (dans cet exemple) de
+     0,35&nbsp;%. La fréquence de base de la combinaison (telle qu'elle est
+     calculée par les fréquences par mono colonne) est seulement de
+     0,0027&nbsp;%, résultant à une sous-estimation très forte.
     </para>
 
     <para>
-     It's advisable to create <acronym>MCV</acronym> statistics objects only
-     on combinations of columns that are actually used in conditions together,
-     and for which misestimation of the number of groups is resulting in bad
-     plans.  Otherwise, the <command>ANALYZE</command> and planning cycles
-     are just wasted.
+     Il est préférable de créer des objets statistiques <acronym>MCV</acronym>
+     uniquement sur les combinaisons de colonnes réellement utilisées ensemble
+     dans des filtres et pour lesquelles la mauvaise estimation du nombre de
+     groupes a pour conséquence de mauvais plans. Dans le cas contraire, le
+     <command>ANALYZE</command> et le temps de planification sont juste
+     gâchés.
     </para>
    </sect3>
 

postgresql/ref/grant.xml

@@ -167,7 +167,7 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
      <term><literal>USAGE</literal></term>
      <listitem>
       <para>
-       Specific types of privileges, as defined in <xref linkend="ddl-priv"/>.
+       Types spécifiques de droits, comme définis dans <xref linkend="ddl-priv"/>.
       </para>
      </listitem>
     </varlistentry>
@@ -176,7 +176,7 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
      <term><literal>TEMP</literal></term>
      <listitem>
       <para>
-       Alternative spelling for <literal>TEMPORARY</literal>.
+       Autre écriture de <literal>TEMPORARY</literal>.
       </para>
      </listitem>
     </varlistentry>
@@ -185,34 +185,34 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
      <term><literal>ALL PRIVILEGES</literal></term>
      <listitem>
       <para>
-       Grant all of the privileges available for the object's type.
-       The <literal>PRIVILEGES</literal> key word is optional in
-       <productname>PostgreSQL</productname>, though it is required by
-       strict SQL.
+       Donner tous les droits disponibles pour ce type d'objet. Le mot-clé
+       <literal>PRIVILEGES</literal> est optionnel dans
+       <productname>PostgreSQL</productname>, bien qu'il soit requis en SQL.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
 
   <para>
-   The <literal>FUNCTION</literal> syntax works for plain functions,
-   aggregate functions, and window functions, but not for procedures;
-   use <literal>PROCEDURE</literal> for those.
-   Alternatively, use <literal>ROUTINE</literal> to refer to a function,
-   aggregate function, window function, or procedure regardless of its
-   precise type.
+   La syntaxe <literal>FUNCTION</literal> fonctionne pour les fonctions
+   simples, les fonctions d'agrégat, et les fonctions de fenêtrage, mais pas
+   pour les procédures&nbsp;; utilisez <literal>PROCEDURE</literal> pour ces
+   dernières. Vous pouvez aussi utiliser <literal>ROUTINE</literal> pour faire
+   référence à une fonction simple, une fonction d'agrégat, une fonction de
+   fenêtrage ou une procédure.
   </para>
 
   <para>
-   There is also an option to grant privileges on all objects of the same
-   type within one or more schemas.  This functionality is currently supported
-   only for tables, sequences, functions, and procedures.  <literal>ALL
-   TABLES</literal> also affects views and foreign tables, just like the
-   specific-object <command>GRANT</command> command.  <literal>ALL
-   FUNCTIONS</literal> also affects aggregate and window functions, but not
-   procedures, again just like the specific-object <command>GRANT</command>
-   command.  Use <literal>ALL ROUTINES</literal> to include procedures.
+   Il existe aussi une option pour donner les droits sur tous les objets de
+   même type dans un ou plusieurs schémas. Cette fonctionnalité est
+   actuellement supportée par les tables, séquences, fonctions et procédures.
+   <literal>ALL TABLES</literal> affecte aussi les vues et les tables
+   externes, tout comme la commande <command>GRANT</command> de cet objet. 
+   <literal>ALL FUNCTIONS</literal> affecte aussi les fonctions d'agrégat et
+   les fonctions de fenêtrage, mais pas les procédures, encore une fois tout
+   comme la commande <command>GRANT</command> spécifique à l'objet. Utilisez
+   <literal>ALL ROUTINES</literal> pour inclure les procédures.
    </para>
   </refsect2>
 
@@ -334,8 +334,9 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
   </para>
 
   <para>
-   See <xref linkend="ddl-priv"/> for more information about specific
-   privilege types, as well as how to inspect objects' privileges.
+   Voir <xref linkend="ddl-priv"/> pour plus d'informations sur les types de
+   droit spécifiques, ainsi que sur la façon d'inspecter les droits sur les
+   objets.
   </para>
  </refsect1>
 

postgresql/ref/select.xml

@@ -242,7 +242,7 @@ TABLE [ ONLY ] <replaceable class="parameter">nom_table</replaceable> [ * ]
     C'est la sortie de cette clause <literal>RETURNING</literal>, <emphasis>et non pas</emphasis> la table sous-jacente
     que l'ordre modifie, qui donne lieu à la table temporaire lue par la requête principale.
     Si la clause <literal>RETURNING</literal> est omise, l'ordre est tout de même exécuté,
-    mais il ne produit pas de sortie ; il ne peut donc pas être référencé comme une table
+    mais il ne produit pas de sortie&nbsp;; il ne peut donc pas être référencé comme une table
     par la requête principale.
    </para>
 
@@ -279,12 +279,13 @@ TABLE [ ONLY ] <replaceable class="parameter">nom_table</replaceable> [ * ]
    </para>
 
    <para>
-    The primary query and the <literal>WITH</literal> queries are all
-    (notionally) executed at the same time.  This implies that the effects of
-    a data-modifying statement in <literal>WITH</literal> cannot be seen from
-    other parts of the query, other than by reading its <literal>RETURNING</literal>
-    output.  If two such data-modifying statements attempt to modify the same
-    row, the results are unspecified.
+    La requête principale et les requêtes <literal>WITH</literal> sont toutes
+    exécutées en même temps. Ceci implique que les effets d'une requête
+    modifiant des données dans la clause <literal>WITH</literal> ne peuvent
+    pas être vus des autres parties de la requête, autrement qu'en lisant son
+    retour avec la clause <literal>RETURNING</literal>. Si des telles
+    instructions de modification de données essaient de modifier la même
+    ligne, les résultats sont inconnus.
    </para>
 
    <para>
@@ -296,35 +297,37 @@ TABLE [ ONLY ] <replaceable class="parameter">nom_table</replaceable> [ * ]
    </para>
 
    <para>
-    However, a <literal>WITH</literal> query can be marked
-    <literal>NOT MATERIALIZED</literal> to remove this guarantee.  In that
-    case, the <literal>WITH</literal> query can be folded into the primary
-    query much as though it were a simple sub-<literal>SELECT</literal> in
-    the primary query's <literal>FROM</literal> clause.  This results in
-    duplicate computations if the primary query refers to
-    that <literal>WITH</literal> query more than once; but if each such use
-    requires only a few rows of the <literal>WITH</literal> query's total
-    output, <literal>NOT MATERIALIZED</literal> can provide a net savings by
-    allowing the queries to be optimized jointly.
-    <literal>NOT MATERIALIZED</literal> is ignored if it is attached to
-    a <literal>WITH</literal> query that is recursive or is not
-    side-effect-free (i.e., is not a plain <literal>SELECT</literal>
-    containing no volatile functions).
+    Néanmoins, une requête <literal>WITH</literal> peut être marquée
+    <literal>NOT MATERIALIZED</literal> pour supprimer cette garantie. Dans ce
+    cas, la requête <literal>WITH</literal> peut être intégrée dans la requête
+    principale comme s'il s'agissait d'un simple
+    sous-<literal>SELECT</literal> dans la clause <literal>FROM</literal> de
+    la requête principale. Ceci résulte en des calculs dupliquées sur la
+    requête principale fait référence à la requête <literal>WITH</literal>
+    plus d'une fois&nbsp;; mais si chaque utilisation requiert seulement
+    quelques lignes de la sortie complète de la requête
+    <literal>WITH</literal>, la clause <literal>NOT MATERIALIZED</literal>
+    peut apporter un gain net en autorisant les requêtes à être optimisées
+    globalement. <literal>NOT MATERIALIZED</literal> est ignoré s'il est
+    attaché à une requête <literal>WITH</literal> récursive ou qui n'est pas
+    sans effet de bord (autrement dit, pas un simple <literal>SELECT</literal>
+    contenant aucune fonction volatile).
    </para>
 
    <para>
-    By default, a side-effect-free <literal>WITH</literal> query is folded
-    into the primary query if it is used exactly once in the primary
-    query's <literal>FROM</literal> clause.  This allows joint optimization
-    of the two query levels in situations where that should be semantically
-    invisible.  However, such folding can be prevented by marking the
-    <literal>WITH</literal> query as <literal>MATERIALIZED</literal>.
-    That might be useful, for example, if the <literal>WITH</literal> query
-    is being used as an optimization fence to prevent the planner from
-    choosing a bad plan.
-    <productname>PostgreSQL</productname> versions before v12 never did
-    such folding, so queries written for older versions might rely on
-    <literal>WITH</literal> to act as an optimization fence.
+    Par défaut, une requête <literal>WITH</literal> sans effet de bord est
+    intégrée dans la requête principale si elle est utilisée exactement une
+    fois dans la clause <literal>FROM</literal> de la requête. Ceci permet une
+    optimisation de la jointure des deux requêtes dans des situations où cela
+    serait sémantiquement invisible. Néanmoins, cette intégration peut être
+    empêchée en marquant la requête <literal>WITH</literal> avec le mot-clé
+    <literal>MATERIALIZED</literal>. Ceci peut être utile si la requête
+    <literal>WITH</literal> est utilisée comme barrière d'optimisation pour
+    empêcher le planificateur de choisir un mauvais plan. Les versions de
+    <productname>PostgreSQL</productname> antérieures à la 12 ne faisaient
+    jamais ce type d'intégration, donc les requêtes écrites pour les versions
+    précédentes pourraient se fier sur <literal>WITH</literal> comme barrières
+    d'optimisation.
    </para>
 
    <para>
@@ -1173,7 +1176,7 @@ SELECT DISTINCT ON (lieu) lieu, heure, rapport
    </para>
 
    <para>
-    La (ou les ) expression(s) <literal>DISTINCT ON</literal> doivent correspondre à l'expression (ou aux expressions)
+    La (ou les) expression(s) <literal>DISTINCT ON</literal> doivent correspondre à l'expression (ou aux expressions)
     <literal>ORDER BY</literal> la(les) plus à gauche.  La clause <literal>ORDER BY</literal>  contient habituellement des
     expressions supplémentaires qui déterminent l'ordre des lignes au sein de chaque groupe <literal>DISTINCT ON</literal>.
    </para>
@@ -1218,7 +1221,7 @@ SELECT DISTINCT ON (lieu) lieu, heure, rapport
     empêche l'élimination des lignes dupliquées. <literal>UNION
      ALL</literal> est donc significativement plus rapide qu'<literal>UNION</literal>,
     et sera préféré. <literal>DISTINCT</literal> peut éventuellement être ajouté pour préciser explicitement
-    le comportement par défaut : l'élimination des lignes en double.
+    le comportement par défaut&nbsp;: l'élimination des lignes en double.
    </para>
 
    <para>
@@ -1264,7 +1267,7 @@ SELECT DISTINCT ON (lieu) lieu, heure, rapport
     apparaît min(<replaceable>m</replaceable>,<replaceable>n</replaceable>) fois dans
     l'ensemble de résultats.
     <literal>DISTINCT</literal> peut éventuellement être ajouté pour préciser explicitement
-    le comportement par défaut : l'élimination des lignes en double.
+    le comportement par défaut&nbsp;: l'élimination des lignes en double.
    </para>
 
    <para>
@@ -1313,7 +1316,7 @@ SELECT DISTINCT ON (lieu) lieu, heure, rapport
     apparaît max(<replaceable>m</replaceable>-<replaceable>n</replaceable>,0) fois dans
     l'ensemble de résultats.
     <literal>DISTINCT</literal> peut éventuellement être ajouté pour préciser explicitement
-    le comportement par défaut : l'élimination des lignes en double.
+    le comportement par défaut&nbsp;: l'élimination des lignes en double.
    </para>
 
    <para>
@@ -2108,7 +2111,7 @@ FROM manufacturiers m LEFT JOIN LATERAL recupere_nom_produits(m.id) pnom ON true
     (Les applications écrites pour <productname>Oracle</productname> contournent
     fréquemment le problème par l'utilisation de la colonne auto-générée
     <literal>rownum</literal> pour obtenir les effets de ces clauses, qui n'est
-    pas disponible sous PostgreSQL,)
+    pas disponible sous PostgreSQL).
    </para>
   </refsect2>
 
@@ -2151,9 +2154,9 @@ FROM manufacturiers m LEFT JOIN LATERAL recupere_nom_produits(m.id) pnom ON true
    </para>
 
    <para>
-    The <literal>MATERIALIZED</literal> and <literal>NOT
-    MATERIALIZED</literal> options of <literal>WITH</literal> are extensions
-    of the SQL standard.
+    Les options <literal>MATERIALIZED</literal> et <literal>NOT
+    MATERIALIZED</literal> de la clause <literal>WITH</literal> sont des
+    extensions au standard SQL.
    </para>
   </refsect2>
  </refsect1>