Les dernières traductions de cette version mineure

postgresql/ref/psql-ref.xml

@@ -55,8 +55,8 @@
       <listitem>
       <para>
        Affiche toutes les lignes non vides en entrée sur la sortie standard
-       lorsqu'elles sont lues. (This does not apply to lines read
-       interactively.) C'est équivalent à initialiser la variable
+       lorsqu'elles sont lues. (Ceci ne s'applique pas aux lignes lues de
+       façon interactive.) C'est équivalent à initialiser la variable
        <varname>ECHO</varname> à <literal>all</literal>.
       </para>
       </listitem>
@@ -1804,11 +1804,11 @@ lo_import 152801
         <term><literal>\o</literal> or <literal>\out [ |<replaceable class="parameter">commande</replaceable> ]</literal></term>
         <listitem>
         <para>
-        Arranges to save future query results to the file <replaceable
-        class="parameter">filename</replaceable> or pipe future results
-        to the shell command <replaceable
-        class="parameter">command</replaceable>. If no argument is
-        specified, the query output is reset to the standard output.
+        S'arrange pour sauvegarder les résultats des prochaines requêtes dans
+        le fichier <replaceable class="parameter">nomfichier</replaceable> ou
+        d'envoyer les résultats à la commande shell <replaceable
+        class="parameter">commande</replaceable>. Si aucun argument n'est
+        fourni, le résultat de la requête va sur la sortie standard.
         </para>
 
 	<para>
@@ -2245,13 +2245,14 @@ lo_import 152801
 	class="parameter">nomfichier</replaceable> ]</literal></term>
         <listitem>
         <para>
-        Print <application>psql</application>'s command line history
-        to <replaceable class="parameter">filename</replaceable>.
-        If <replaceable class="parameter">filename</replaceable> is omitted,
-        the history is written to the standard output (using the pager if
-        appropriate).  This command is not available
-        if <application>psql</application> was built
-        without <application>Readline</application> support.
+        Sauvegarde l'historique de la ligne de commande de
+        <application>psql</application> dans <replaceable
+        class="parameter">nomfichier</replaceable>. Si <replaceable
+        class="parameter">nomfichier</replaceable> est omis, l'historique est
+        écrit sur la sortie standard (en utilisant le paginateur si
+        nécessaire). Cette commande n'est pas disponible si
+        <application>psql</application> a été construit sans le support de
+        <application>Readline</application>.
         </para>
 
         </listitem>

postgresql/runtime.xml

@@ -794,19 +794,20 @@ options "SEMMNS=240"</programlisting>
        </para>
 
        <para>
-        These semaphore-related settings are read-only as far as
-        <command>sysctl</command> is concerned, but can be set in
-        <filename>/boot/loader.conf</filename>:
+        Ces paramètres relatifs aux sémaphores sont en lecture seule en ce qui
+        concerne <command>sysctl</command>, mais peuvent être configurés dans
+        <filename>/boot/loader.conf</filename>&nbsp;:
 <programlisting>
 kern.ipc.semmni=256
 kern.ipc.semmns=512
 kern.ipc.semmnu=256
 </programlisting>
-        After modifying these values a reboot is required for the new
-        settings to take effect.
-        (Note: FreeBSD does not use <varname>SEMMAP</varname>.  Older versions
-        would accept but ignore a setting for <literal>kern.ipc.semmap</literal>;
-        newer versions reject it altogether.)
+        Après modification de ces valeurs, un redémarrage est nécessaire pour
+        que les nouvelles valeurs prennent effet.
+        (Note&nbsp;: FreeBSD n'utilise pas <varname>SEMMAP</varname>. Les
+        anciennes versions accepteraient, tout en l'ignorant, une configuration
+        de <literal>kern.ipc.semmap</literal>&nbsp;; les nouvelles versions la
+        rejettent directement.)
        </para>
 
        <para>

postgresql/syntax.xml

@@ -2248,52 +2248,54 @@ SELECT ROW(table.*) IS NULL FROM table; -- détecte toutes les lignes non NULL</
    </para>
 
    <para>
-    <literal>CASE</literal> is not a cure-all for such issues, however.
-    One limitation of the technique illustrated above is that it does not
-    prevent early evaluation of constant subexpressions.
-    As described in <xref linkend="xfunc-volatility"/>, functions and
-    operators marked <literal>IMMUTABLE</literal> can be evaluated when
-    the query is planned rather than when it is executed.  Thus for example
+    Néanmoins, <literal>CASE</literal> n'est pas un remède à tout. Une limitation
+    à la technique illustrée ci-dessus est qu'elle n'empêche pas l'évaluation
+    en avance des sous-expressions constantes. Comme décrit dans <xref
+    linkend="xfunc-volatility"/>, les fonctions et les opérateurs marqués
+    <literal>IMMUTABLE</literal> peuvent être évalués quand la requête est
+    planifiée plutôt que quand elle est exécutée. Donc, par exemple&nbsp;:
 <programlisting>
 SELECT CASE WHEN x &gt; 0 THEN x ELSE 1/0 END FROM tab;
 </programlisting>
-    is likely to result in a division-by-zero failure due to the planner
-    trying to simplify the constant subexpression,
-    even if every row in the table has <literal>x &gt; 0</literal> so that the
-    <literal>ELSE</literal> arm would never be entered at run time.
+    va produire comme résultat un échec pour division par zéro car le
+    planificateur a essayé de simplifier la sous-expression constante, même
+    si chaque ligne de la table a <literal>x &gt; 0</literal> de façon à ce
+    que la condition <literal>ELSE</literal> ne soit jamais exécutée.
    </para>
 
    <para>
-    While that particular example might seem silly, related cases that don't
-    obviously involve constants can occur in queries executed within
-    functions, since the values of function arguments and local variables
-    can be inserted into queries as constants for planning purposes.
-    Within <application>PL/pgSQL</application> functions, for example, using an
-    <literal>IF</literal>-<literal>THEN</literal>-<literal>ELSE</literal> statement to protect
-    a risky computation is much safer than just nesting it in a
-    <literal>CASE</literal> expression.
+    Bien que cet exemple particulier puisse sembler stupide, il existe de
+    nombreux cas moins évident, n'impliquant pas de constantes, mais plutôt
+    des requêtes exécutées par des fonctions, quand les valeurs des arguments
+    des fonctions et de variables locales peuvent être insérées dans les requêtes
+    en tant que constantes toujours dans le but de la planification. À l'intéreur
+    de fonctions <application>PL/pgSQL</application>, par exemple, en utilisant
+    une instruction <literal>IF</literal>-<literal>THEN</literal>-
+    <literal>ELSE</literal> pour proteger un calcul risqué est beaucoup plus sûr
+    que dans une expression <literal>CASE</literal>.
    </para>
 
    <para>
-    Another limitation of the same kind is that a <literal>CASE</literal> cannot
-    prevent evaluation of an aggregate expression contained within it,
-    because aggregate expressions are computed before other
-    expressions in a <literal>SELECT</literal> list or <literal>HAVING</literal> clause
-    are considered.  For example, the following query can cause a
-    division-by-zero error despite seemingly having protected against it:
+    Une limitation de même type est qu'un <literal>CASE</literal> ne peut
+    pas empêcher l'évaluation d'une expression d'agrégat qui y est contenue
+    car les expressions d'agrégat sont calculées avant que les autres
+    expressions dans une liste <literal>SELECT</literal> et dans une clause
+    <literal>HAVING</literal> ne soient considérées. Par exemple, la requête
+    suivante peut causer une erreur de division par zéro bien qu'elle semble
+    protéger contre ce problème&nbsp;:
 <programlisting>
 SELECT CASE WHEN min(employees) > 0
             THEN avg(expenses / employees)
        END
     FROM departments;
 </programlisting>
-    The <function>min()</function> and <function>avg()</function> aggregates are computed
-    concurrently over all the input rows, so if any row
-    has <structfield>employees</structfield> equal to zero, the division-by-zero error
-    will occur before there is any opportunity to test the result of
-    <function>min()</function>.  Instead, use a <literal>WHERE</literal>
-    clause to prevent problematic input rows from
-    reaching an aggregate function in the first place.
+    Les agrégats <function>min()</function> et <function>avg()</function> sont
+    calculés en même temps sur toutes les lignes en entrée, donc si une ligne
+    a sa colonne <structfield>employees</structfield> à zéro, l'erreur de
+    division par zéro surviendra avant le test du résultat de
+    <function>min()</function>. Utilisez à la place une clause
+    <literal>WHERE</literal> pour empêcher les lignes problématiques en entrée
+    d'atteindre la fonction d'agrégat.
    </para>
   </sect2>
  </sect1>

postgresql/typeconv.xml

@@ -290,9 +290,10 @@ une donnée de type <type>unknown</type> ne trouveront jamais une correspondance
 </step>
 <step id="op-resol-exact-domain" performance="optional">
 <para>
-If one argument of a binary operator invocation is of the <type>unknown</type>
-type and the other is of a domain type, next check to see if there is an
-operator accepting exactly the domain's base type on both sides; if so, use it.
+Si un argument de l'appel d'une invocation d'opérateur binaire est de type
+<type>unknown</type> et que l'autre est un domaine, alors vérifier s'il existe
+un type acceptant exactement le type de base du domaine sur les deux côtés et,
+dans ce cas, l'utiliser.
 </para>
 </step>
 </substeps>
@@ -315,9 +316,9 @@ prochaine étape.
 </step>
 <step performance="required">
 <para>
-If any input argument is of a domain type, treat it as being of the
-domain's base type for all subsequent steps.  This ensures that domains
-act like their base types for purposes of ambiguous-operator resolution.
+Si un des arguments est de type domaine, le traiter comme le type de base du
+domaine pour les étapes suivantes. Ceci assure que les domaines agissent comme
+leur type de base dans le cas de résolution d'opérateur ambigue.
 </para>
 </step>
 <step performance="required">
@@ -493,41 +494,45 @@ possibles.  Nous pouvons l'aider avec une conversion explicite&nbsp;:
 </example>
 
 <example>
-<title>Custom Operator on a Domain Type</title>
+<title>Opérateur personnalisé sur un type domaine</title>
 
 <para>
-Users sometimes try to declare operators applying just to a domain type.
-This is possible but is not nearly as useful as it might seem, because the
-operator resolution rules are designed to select operators applying to the
-domain's base type.  As an example consider
+  Quelque fois, les utilisateurs essaient de déclarer des opérateurs
+  s'appliquant uniquement sur un type domaine. Ceci est possible mais n'est
+  pas aussi utile que cela paraît parce que les règles de résolution
+  d'opérateur sont conçues pour sélectionner les opérateurs qui s'appliquent
+  au type de base du domaine. En voici un exemple&nbsp;:
 <screen>
-CREATE DOMAIN mytext AS text CHECK(...);
-CREATE FUNCTION mytext_eq_text (mytext, text) RETURNS boolean AS ...;
-CREATE OPERATOR = (procedure=mytext_eq_text, leftarg=mytext, rightarg=text);
-CREATE TABLE mytable (val mytext);
+CREATE DOMAIN montexte AS text CHECK(...);
+CREATE FUNCTION montexte_eq_text (montexte, text) RETURNS boolean AS ...;
+CREATE OPERATOR = (procedure=montexte_eq_text, leftarg=montexte, rightarg=text);
+CREATE TABLE matable (val montexte);
 
-SELECT * FROM mytable WHERE val = 'foo';
+SELECT * FROM matable WHERE val = 'foo';
 </screen>
-This query will not use the custom operator.  The parser will first see if
-there is a <type>mytext</type> <literal>=</literal> <type>mytext</type> operator
-(<xref linkend="op-resol-exact-unknown"/>), which there is not;
-then it will consider the domain's base type <type>text</type>, and see if
-there is a <type>text</type> <literal>=</literal> <type>text</type> operator
-(<xref linkend="op-resol-exact-domain"/>), which there is;
-so it resolves the <type>unknown</type>-type literal as <type>text</type> and
-uses the <type>text</type> <literal>=</literal> <type>text</type> operator.
-The only way to get the custom operator to be used is to explicitly cast
-the literal:
+  Cette requête n'utilisera pas l'opérateur personnalisé. L'analyseur va tout
+  d'abord voir s'il existe un opérateur <type>montexte</type>
+  <literal>=</literal> <type>montexte</type> (<xref
+  linkend="op-resol-exact-unknown"/>). Comme il n'existe pas, il considérera
+  le type de base du domaine, <type>text</type>, et cherchera un opérateur
+  <type>text</type> <literal>=</literal> <type>text</type> (<xref
+  linkend="op-resol-exact-domain"/>), qui, lui, existe&nbsp;; donc il résout
+  le litéral de type <type>unknown</type> en type <type>text</type> et utilise
+  l'opérateur <type>text</type> <literal>=</literal> <type>text</type>. La seule
+  façon d'obtenir l'utilisation de l'opérateur spécialisé est de convertir
+  explicitement le litéral&nbsp;:
 <screen>
-SELECT * FROM mytable WHERE val = text 'foo';
+SELECT * FROM matable WHERE val = text 'foo';
 </screen>
-so that the <type>mytext</type> <literal>=</literal> <type>text</type> operator is found
-immediately according to the exact-match rule.  If the best-match rules
-are reached, they actively discriminate against operators on domain types.
-If they did not, such an operator would create too many ambiguous-operator
-failures, because the casting rules always consider a domain as castable
-to or from its base type, and so the domain operator would be considered
-usable in all the same cases as a similarly-named operator on the base type.
+  pour que l'opérateur <type>montexte</type> <literal>=</literal>
+  <type>text</type> soit trouvé immédiatement suivant les règles de
+  correspondance exacte. Si ces règles offrent une correspondance exacte,
+  elles discriminent activement les opérateurs sur des types domaines. Dans le
+  cas contraire, ce type d'opérateur pourrait créer trop d'échecs à cause
+  d'opérateurs ambigues car les règles de conversion considèrent toujours un
+  domaine comme convertissable vers ou à partir du type de base, et donc
+  l'opérateur sur le domaine serait considéré comme utilisable sur tous les
+  cas où un opérateur de même nom sur le type de base le serait.
 </para>
 </example>
 
@@ -652,9 +657,9 @@ Si un seul candidat reste, utiliser le&nbsp;; sinon, aller à la prochaine
 </step>
 <step performance="required">
 <para>
-If any input argument is of a domain type, treat it as being of the
-domain's base type for all subsequent steps.  This ensures that domains
-act like their base types for purposes of ambiguous-function resolution.
+Si un des arguments est de type domaine, le traiter comme le type de base du
+domaine pour toutes les étapes suivantes. Ceci assure que les domaines agissent
+comme leur type de base pour la résolution de fonctions ambigues.
 </para>
 </step>
 <step performance="required">
@@ -966,15 +971,16 @@ chaîne).
 
 <step performance="required">
 <para>
-If any input is of a domain type, treat it as being of the
-domain's base type for all subsequent steps.
+Si un argument est de type domaine, le traiter comme le type de base du domaine
+pour toutes les étapes suivantes.
   <footnote>
    <para>
-    Somewhat like the treatment of domain inputs for operators and
-    functions, this behavior allows a domain type to be preserved through
-    a <literal>UNION</literal> or similar construct, so long as the user is
-    careful to ensure that all inputs are implicitly or explicitly of that
-    exact type.  Otherwise the domain's base type will be preferred.
+    Ressemblant un peu au traitement des arguments de type domaine pour les
+    opérateurs et les fonctions, ce comportement permet à un type domaine
+    d'être préservé à travers un <literal>UNION</literal> ou une construction
+    similaire, si tant est que l'utilisateur fait attention à ce que tous
+    les arguments soient implicitement ou explicitement de ce type même.
+    Sinon le type de base du domaine sera préféré.
    </para>
   </footnote>
 </para>

postgresql/xfunc.xml

@@ -671,17 +671,19 @@ SELECT mleast(VARIADIC ARRAY[10, -1, 5, 4.4]);
     </para>
 
     <para>
-     Specifying <literal>VARIADIC</literal> in the call is also the only way to
-     pass an empty array to a variadic function, for example:
+     Spécifier <literal>VARIADIC</literal> dans l'appel est aussi la seule
+     façon de passer un tableau vide à une fonction variadique. Par
+     exemple&nbsp;:
 
 <screen>
 SELECT mleast(VARIADIC ARRAY[]::numeric[]);
 </screen>
 
-     Simply writing <literal>SELECT mleast()</literal> does not work because a
-     variadic parameter must match at least one actual argument.
-     (You could define a second function also named <literal>mleast</literal>,
-     with no parameters, if you wanted to allow such calls.)
+     Écrire simplement <literal>SELECT mleast()</literal> ne fonctionne pas
+     car un paramètre variadique doit correspondre à au moins un argument
+     réel. (Vous pouvez définir une deuxième fonction aussi nommée
+     <literal>mleast</literal>, sans paramètres, si vous voulez permettre ce
+     type d'appels.)
     </para>
 
     <para>