[Trad] [svn:pgfr] r1358 - traduc/trunk/postgresql

[admin at listes.postgresql.fr]

Author: gleu
Date: 2009-06-28 00:42:59 +0200 (Sun, 28 Jun 2009)
New Revision: 1358

Modified:
   traduc/trunk/postgresql/gist.xml
Log:
Derni?\195?\168re traduction pour la 8.4.0.


Modified: traduc/trunk/postgresql/gist.xml
===================================================================
--- traduc/trunk/postgresql/gist.xml	2009-06-27 16:40:21 UTC (rev 1357)
+++ traduc/trunk/postgresql/gist.xml	2009-06-27 22:42:59 UTC (rev 1358)
@@ -109,19 +109,21 @@
  
  <para>
    Une classe d'opérateur d'index <acronym>GiST</acronym> doit fournir sept
-   méthodes. Correctness of the index is ensured
-   by proper implementation of the <function>same</function>, <function>consistent</function>
-   and <function>union</function> methods, while efficiency (size and speed) of the
-   index will depend on the <function>penalty</function> and <function>picksplit</function>
-   methods.
-   The remaining two methods are <function>compress</function> and
-   <function>decompress</function>, which allow an index to have internal tree data of
-   a different type than the data it indexes. The leaves are to be of the
-   indexed data type, while the other tree nodes can be of any C struct (but
-   you still have to follow <productname>PostgreSQL</productname> datatype rules here,
-   see about <literal>varlena</literal> for variable sized data). If the tree's
-   internal data type exists at the SQL level, the <literal>STORAGE</literal> option
-   of the <command>CREATE OPERATOR CLASS</command> command can be used.
+   méthodes. La précision de l'index est assurée par l'implantation des
+   méthodes <function>same</function>, <function>consistent</function>
+   et <function>union</function> alors que l'efficacité (taille et rapidité)
+   de l'index dépendra des méthodes <function>penalty</function> et
+   <function>picksplit</function>. Les deux fonctions restantes sont
+   <function>compress</function> et <function>decompress</function>, qui
+   permettent à un index d'avoir des données internes de l'arbre d'un type
+   différent de ceux des données qu'il indexe. Les feuilles doivent être du
+   type des données indexées alors que les autres n&oelig;uds peuvent être de
+   n'importe quelle structure C (mais vous devez toujours suivre les règles
+   des types de données de <productname>PostgreSQL</productname> dans ce cas,
+   voir ce qui concerne <literal>varlena</literal> pour les données de taille
+   variable). Si le type de données interne de l'arbre existe au niveau SQL,
+   l'option <literal>STORAGE</literal> de la commande <command>CREATE OPERATOR
+   CLASS</command> peut être utilisée.
  </para>
 
  <variablelist>
@@ -129,25 +131,28 @@
      <term><function>consistent</function></term>
      <listitem>
       <para>
-       Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
-       this function determines whether the index entry is
-       <quote>consistent</quote> with the query; that is, could the predicate
-       <quote><replaceable>indexed_column</replaceable>
-       <replaceable>indexable_operator</replaceable> <literal>q</literal></quote> be true for
-       any row represented by the index entry?  For a leaf index entry this is
-       equivalent to testing the indexable condition, while for an internal
-       tree node this determines whether it is necessary to scan the subtree
-       of the index represented by the tree node.  When the result is
-       <literal>true</literal>, a <literal>recheck</literal> flag must also be returned.
-       This indicates whether the predicate is certainly true or only possibly
-       true.  If <literal>recheck</literal> = <literal>false</literal> then the index has
-       tested the predicate condition exactly, whereas if <literal>recheck</literal>
-       = <literal>true</literal> the row is only a candidate match.  In that case the
-       system will automatically evaluate the
-       <replaceable>indexable_operator</replaceable> against the actual row value to see
-       if it is really a match.  This convention allows
-       <acronym>GiST</acronym> to support both lossless and lossy index
-       structures.
+       Étant donné une entrée d'index <literal>p</literal> et une valeur de
+       requête <literal>q</literal>, cette fonction détermine si l'entrée de
+       l'index est cohérente (<quote>consistent</quote> en anglais) avec la
+       requête&nbsp;; c'est-à-dire, est-ce que le prédicat
+       <quote><replaceable>colonne_indexée</replaceable>
+       <replaceable>opérateur_indexable</replaceable> <literal>q</literal></quote>
+       soit vrai pour toute ligne représentée par l'entrée de l'index&nbsp;?
+       Pour une entrée de l'index de type feuille, c'est l'équivalent pour
+       tester la condition indexable, alors que pour un n&oelig;ud interne de
+       l'arbre, ceci détermine s'il est nécessaire de parcourir le sous-arbre de
+       l'index représenté par le n&oelig;ud. Quand le résultat est
+       <literal>true</literal>, un drapeau <literal>recheck</literal> doit
+       aussi être renvoyé. Ceci indique si le prédicat est vrai à coup sûr ou
+       seulement peut-être vrai. Si <literal>recheck</literal> =
+       <literal>false</literal>, alors l'index a testé exactement la condition
+       du prédicat, alors que si <literal>recheck</literal>
+       = <literal>true</literal>, la ligne est seulement un correspondance de
+       candidat. Dans ce cas, le système évaluera automatiquement
+       l'<replaceable>opérateur_indexable</replaceable> avec la valeur actuelle
+       de la ligne pour voir s'il s'agit réellement d'une correspondance. Cette
+       convention permet à <acronym>GiST</acronym> de supporter à la fois les
+       structures sans pertes et celles avec perte de l'index.
       </para>
 
       <para>