Traduction v11 de xindex.xml

postgresql/xindex.xml

@@ -469,10 +469,10 @@
      </row>
      <row>
       <entry>
-        Compute the 64-bit hash value for a key given a 64-bit salt; if
-        the salt is 0, the low 32 bits of the result must match the value
-        that would have been computed by function 1
-        (optional)
+        Calcule la valeur de hashage sur 64 bits d'une clé pour un sel de
+        64 bits donné; si le sel vaut 0, les 32 bits de poids faible du
+        résultat doivent correspondre à la valeur qui aurait été calculée par
+        la fonction 1 (facultative)
       </entry>
       <entry>2</entry>
      </row>
@@ -1192,54 +1192,59 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
    </note>
 
   <para>
-   Sorting by a non-default B-tree operator class is possible by specifying
-   the class's less-than operator in a <literal>USING</literal> option,
-   for example
+   Trier par une classe d'opérateur B-tree qui n'est pas celle par défaut est
+   possible en précisant l'opérateur inférieur-à de la classe dans une option
+   <literal>USING</literal>, par exemple
 <programlisting>
 SELECT * FROM mytable ORDER BY somecol USING ~&lt;~;
 </programlisting>
-   Alternatively, specifying the class's greater-than operator
-   in <literal>USING</literal> selects a descending-order sort.
+   Sinon, préciser l'opérateur supérieur-à de la classe dans un
+   <literal>USING</literal> sélectionne un tri par ordre décroissant.
   </para>
 
   <para>
-   Comparison of arrays of a user-defined type also relies on the semantics
-   defined by the type's default B-tree operator class.  If there is no
-   default B-tree operator class, but there is a default hash operator class,
-   then array equality is supported, but not ordering comparisons.
+   La comparaison de tableaux d'un type de donné utilisateur repose également
+   sur la sémantique définie par la classe d'opérateur B-tree par défaut du
+   type.  S'il n'y a pas de clausse d'opérateur B-tree par défaut, mais qu'il y
+   a une classe d'opérateur de type hash, alors l'égalité de tableau est
+   supportéee, mais pas la comparaison pour les tris.
   </para>
 
   <para>
-   Another SQL feature that requires even more data-type-specific knowledge
-   is the <literal>RANGE</literal> <replaceable>offset</replaceable>
-   <literal>PRECEDING</literal>/<literal>FOLLOWING</literal> framing option
-   for window functions (see <xref linkend="syntax-window-functions"/>).
-   For a query such as
+   Une autre fonctionnalité SQL qui nécessaire une connaissance encore plus
+   spécifique du type de données est l'option
+   <literal>RANGE</literal> <replaceable>offset</replaceable>
+   <literal>PRECEDING</literal>/<literal>FOLLOWING</literal> de fenêtre
+   pour les fonctions de feneêrage (voir <xref linkend="syntax-window-functions"/>).
+   Pour une requête telle que
 <programlisting>
 SELECT sum(x) OVER (ORDER BY x RANGE BETWEEN 5 PRECEDING AND 10 FOLLOWING)
   FROM mytable;
 </programlisting>
-   it is not sufficient to know how to order by <literal>x</literal>;
-   the database must also understand how to <quote>subtract 5</quote> or
-   <quote>add 10</quote> to the current row's value of <literal>x</literal>
-   to identify the bounds of the current window frame.  Comparing the
-   resulting bounds to other rows' values of <literal>x</literal> is
-   possible using the comparison operators provided by the B-tree operator
-   class that defines the <literal>ORDER BY</literal> ordering &mdash; but
-   addition and subtraction operators are not part of the operator class, so
-   which ones should be used?  Hard-wiring that choice would be undesirable,
-   because different sort orders (different B-tree operator classes) might
-   need different behavior.  Therefore, a B-tree operator class can specify
-   an <firstterm>in_range</firstterm> support function that encapsulates the
-   addition and subtraction behaviors that make sense for its sort order.
-   It can even provide more than one in_range support function, in case
-   there is more than one data type that makes sense to use as the offset
-   in <literal>RANGE</literal> clauses.
-   If the B-tree operator class associated with the window's <literal>ORDER
-   BY</literal> clause does not have a matching in_range support function,
-   the <literal>RANGE</literal> <replaceable>offset</replaceable>
+   il n'est pas suffisant de savoir comment trier par <literal>x</literal>;
+   la base de données doit également comprendre comment
+   <quote>soustraire 5</quote> ou <quote>additionner 10</quote> à la valeur de
+   <literal>x</literal> de la ligne courante pour identifier les limites de la
+   fenêtre courante.  Comparer les limites résultantes aux valeurs de
+   <literal>x</literal> des autres lignes est possible en utilisant les
+   opérateurs de comparaison fournis par la classe d'opérateur B-tree qui
+   définit le tri de l'<literal>ORDER BY</literal> &mdash; mais les opérateurs
+   d'addition et de soustraction ne font pas partie de la classe d'opérateur,
+   alors lesquels devraient être utilisés ?  Inscrire en dur ce choix ne serait
+   pas désirable, car différents ordres de tris (différentes classe d'opérateur
+   B-tree) pourraient nécessiter des comportements différents.  Ainsi, une
+   classe d'opérateur B-tree peut préciser une fonction de support
+   <firstterm>in_range</firstterm> qui encapsule les comportements d'addition
+   et de soustraction faisant sens pour son ordre de tri.  Elle peut même
+   fournir plus d'une fonction de support in_range, s'il fait sens d'utiliser
+   plus d'un type de données comme offset dans la clause
+   <literal>RANGE</literal>.
+   Si la classe d'opérateur B-tree associée à la clause<literal>ORDER
+   BY</literal> de la fenêtre n'a pas de fonction de support in_range
+   correspondante, l'option
+   <literal>RANGE</literal> <replaceable>offset</replaceable>
    <literal>PRECEDING</literal>/<literal>FOLLOWING</literal>
-   option is not supported.
+   n'est pas supportée.
   </para>
 
   <para>