Nouveau lot de traductions

postgresql/logicaldecoding.xml

@@ -586,11 +586,11 @@ typedef bool (*LogicalDecodeFilterByOriginCB) (
    </sect3>
 
     <sect3 id="logicaldecoding-output-plugin-message">
-     <title>Generic Message Callback</title>
+     <title>Fonctions personnalisées de message générique</title>
 
      <para>
-      The optional <function>message_cb</function> callback is called whenever
-      a logical decoding message has been decoded.
+      La fonction (callback) <function>message_cb</function> est appelée quand
+      un message de décodage logique a été décodé.
 <programlisting>
 typedef void (*LogicalDecodeMessageCB) (
     struct LogicalDecodingContext *,
@@ -602,22 +602,24 @@ typedef void (*LogicalDecodeMessageCB) (
     const char *message
 );
 </programlisting>
-      The <parameter>txn</parameter> parameter contains meta information about
-      the transaction, like the time stamp at which it has been committed and
-      its XID. Note however that it can be NULL when the message is
-      non-transactional and the XID was not assigned yet in the transaction
-      which logged the message. The <parameter>lsn</parameter> has WAL
-      position of the message. The <parameter>transactional</parameter> says
-      if the message was sent as transactional or not.
-      The <parameter>prefix</parameter> is arbitrary null-terminated prefix
-      which can be used for identifying interesting messages for the current
-      plugin. And finally the <parameter>message</parameter> parameter holds
-      the actual message of <parameter>message_size</parameter> size.
+      Le paramètre <parameter>txn</parameter> contient des méta-informations sur
+      la transaction, comme l'horodatage à laquelle la transaction a été validée
+      et son identifiant (XID). Notez néanmoins qu'il peut être NULL quand le
+      message n'est pas transactionnel et que le XID n'a pas encore été affecté
+      dans la transaction qui a tracé le message. Le <parameter>lsn</parameter>
+      a la position du message dans les WAL. Le paramètre
+      <parameter>transactional</parameter> indique si le message a été envoyé
+      de façon transactionnelle ou non. Le paramètre
+      <parameter>prefix</parameter> est un préfix arbitraire terminé par un
+      un caractère nul qui peut être utilisé pour identifier les messages
+      intéressants pour le plugin courant. Et enfin, le paramètre
+      <parameter>message</parameter> détient le message réel de taille
+      <parameter>message_size</parameter>.
      </para>
      <para>
-      Extra care should be taken to ensure that the prefix the output plugin
-      considers interesting is unique. Using name of the extension or the
-      output plugin itself is often a good choice.
+      Une attention particulière doit être portée à l'unicité du préfixe que le
+      plugin de sortie trouve intéressant. Utiliser le nom de l'extension ou du
+      plugin de sortie est souvent un bon choix.
      </para>
     </sect3>
 

postgresql/mvcc.xml

@@ -707,14 +707,15 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
    <para>
     L'utilisation systématique de transactions Serializable peut
-    simplifier le développement. The guarantee that any set of successfully
-    committed concurrent
-    Serializable transactions will have the same effect as if they were run
-    one at a time means that if you can demonstrate that a single transaction,
-    as written, will do the right thing when run by itself, you can have
-    confidence that it will do the right thing in any mix of Serializable
-    transactions, even without any information about what those other
-    transactions might do, or it will not successfully commit.   Il est important qu'un environnement
+    simplifier le développement. La garantie que tout ensemble de
+    transactions sérialisées concurrentes et validées avec succès
+    auront le même effet que si elles avaient été exécutées une
+    à la fois signifie que, si vous pouvez démontrer qu'une seule
+    transaction fera ce qu'il faut lorsqu'elle est exécutée seule,
+    vous pouvez être certain qu'elle fera ce qu'il faut avec tout
+    mélange de transactions sérialisées, même sans informations sur
+    ce que font les autres transactions, ou elle ne validera pas.
+    Il est important qu'un environnement
     qui utilise cette technique ait une façon généralisée de
     traiter les erreurs de sérialisation (qui retournent toujours
     un SQLSTATE valant '40001'), parce qu'il sera très difficile de
@@ -724,28 +725,30 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
     dépendances lecture/écriture a un coût, tout comme l'échec,
     mais mis en face du coût et du blocage entrainés par les verrous
     explicites et <literal>SELECT FOR UPDATE</literal> ou <literal>SELECT
-     FOR SHARE</literal>, les transactions serializable sont le meilleur
+    FOR SHARE</literal>, les transactions serializable sont le meilleur
     choix en termes de performances pour certains environnements.
    </para>
 
    <para>
-    While <productname>PostgreSQL</productname>'s Serializable transaction isolation
-    level only allows concurrent transactions to commit if it can prove there
-    is a serial order of execution that would produce the same effect, it
-    doesn't always prevent errors from being raised that would not occur in
-    true serial execution.  In particular, it is possible to see unique
-    constraint violations caused by conflicts with overlapping Serializable
-    transactions even after explicitly checking that the key isn't present
-    before attempting to insert it.  This can be avoided by making sure
-    that <emphasis>all</emphasis> Serializable transactions that insert potentially
-    conflicting keys explicitly check if they can do so first.  For example,
-    imagine an application that asks the user for a new key and then checks
-    that it doesn't exist already by trying to select it first, or generates
-    a new key by selecting the maximum existing key and adding one.  If some
-    Serializable transactions insert new keys directly without following this
-    protocol, unique constraints violations might be reported even in cases
-    where they could not occur in a serial execution of the concurrent
-    transactions.
+    Alors que le niveau d'isolation des transactions Serializable de
+    <productname>PostgreSQL</productname> autorise seulement les transactions
+    concurrentes à valider s'il est prouvable qu'il n'y a qu'un ordre sérié
+    d'exécution pouvant produire le même effet, il n'empêche pas toujours
+    les erreurs de survenir bien qu'aucune erreur ne serait levée dans le
+    cas d'une vraie exécution en série. En particulier, il est possible de
+    voir les violations de contrainte unique causées par des conflits avec
+    la surcharge de transactions Serializable même après avoir explicitement
+    vérifié que la clé n'est pas présente avant de tenter son insertion. Ceci
+    peut être évité en s'assurant que <emphasis>toutes</emphasis> les
+    transactions Serializable qui peuvent insérer des  clés potentiellement
+    en conflit commencent par vérifier qu'elles peuvent le faire. Par exemple,
+    imaginez une application qui demande à l'utilisateur une nouvelle clé
+    puis vérifie qu'elle n'existe pas déjà en essayant de la sélectionner,
+    ou génère une nouvelle clé en sélectionnant la clé maximale existante et
+    en ajoutant un. Si certaines transactions Serializable insèrent de nouvelles
+    clés sans suivre ce protocole, des violations de contraintes uniques
+    pourraient être rapportéesmême dans les cas où elles ne surviendraient pas
+    dans une exécution en série des transactions concurrentes.
    </para>
 
    <para>

postgresql/plpython.xml

@@ -1374,9 +1374,9 @@ $$ LANGUAGE plpythonu;
    et <literal>raise plpy.Fatal(<replaceable>msg</replaceable>)</literal> sont
    équivalent à appeler, respectivement,
    <literal>plpy.error(<replaceable>msg</replaceable>)</literal> et
-   <literal>plpy.fatal(<replaceable>msg</replaceable>)</literal>, respectively
-   but the <literal>raise</literal> form does not allow passing keyword
-   arguments. Les autres fonctions génèrent uniquement des messages de
+   <literal>plpy.fatal(<replaceable>msg</replaceable>)</literal>, mais la forme
+   <literal>raise</literal> n'autorise pas de passer des arguments par mot clé.
+   Les autres fonctions génèrent uniquement des messages de
    niveaux de priorité différents. Que les messages d'une priorité particulière
    soient reportés au client, écrit dans les journaux du serveur ou les deux,
    cette configuration est contrôlée par les variables <xref
@@ -1385,19 +1385,21 @@ $$ LANGUAGE plpythonu;
   </para>
 
   <para>
-   The <replaceable>msg</replaceable> argument is given as a positional argument.  For
-   backward compatibility, more than one positional argument can be given. In
-   that case, the string representation of the tuple of positional arguments
-   becomes the message reported to the client.
-   The following keyword-only arguments are accepted:
+   L'argument <replaceable>msg</replaceable> est donné en tant qu'argument de
+   position. Pour des raisons de compatibilité descendante, plus d'un argument
+   de position doit être donné. Dans ce cas, la représentation en chaîne de
+   caractères de la ligne des arguments de position devient le message
+   rapporté au client. Les arguments suivant par mot clé seulement sont
+   acceptés&nbsp;:
    <literal>
    <replaceable>detail</replaceable>, <replaceable>hint</replaceable>,
    <replaceable>sqlstate</replaceable>, <replaceable>schema</replaceable>,
    <replaceable>table</replaceable>, <replaceable>column</replaceable>,
    <replaceable>datatype</replaceable> , <replaceable>constraint</replaceable>
    </literal>.
-   The string representation of the objects passed as keyword-only arguments
-   is used to enrich the messages reported to the client. For example:
+   La représentation en chaine des objets passés en argument par mot clé
+   seulement est utilisé pour enrichir les messages rapportés au client.
+   Par exemple&nbsp;:
 
 <programlisting>
 CREATE FUNCTION raise_custom_exception() RETURNS void AS $$

postgresql/ref/create_function.xml

@@ -432,35 +432,40 @@
     <term><literal>PARALLEL</literal></term>
 
     <listitem>
-     <para><literal>PARALLEL UNSAFE</literal> indicates that the function
-      can't be executed in parallel mode and the presence of such a
-      function in an SQL statement forces a serial execution plan.  This is
-      the default.  <literal>PARALLEL RESTRICTED</literal> indicates that
-      the function can be executed in parallel mode, but the execution is
-      restricted to parallel group leader.  <literal>PARALLEL SAFE</literal>
-      indicates that the function is safe to run in parallel mode without
-      restriction.
-     </para>
-
-     <para>
-      Functions should be labeled parallel unsafe if they modify any database
-      state, or if they make changes to the transaction such as using
-      sub-transactions, or if they access sequences or attempt to make
-      persistent changes to settings (e.g. <literal>setval</literal>).  They should
-      be labeled as parallel restricted if they access temporary tables,
-      client connection state, cursors, prepared statements, or miscellaneous
-      backend-local state which the system cannot synchronize in parallel mode
-      (e.g.  <literal>setseed</literal> cannot be executed other than by the group
-      leader because a change made by another process would not be reflected
-      in the leader).  In general, if a function is labeled as being safe when
-      it is restricted or unsafe, or if it is labeled as being restricted when
-      it is in fact unsafe, it may throw errors or produce wrong answers
-      when used in a parallel query.  C-language functions could in theory
-      exhibit totally undefined behavior if mislabeled, since there is no way
-      for the system to protect itself against arbitrary C code, but in most
-      likely cases the result will be no worse than for any other function.
-      If in doubt, functions should be labeled as <literal>UNSAFE</literal>, which is
-      the default.
+     <para><literal>PARALLEL UNSAFE</literal> indique que la fonction ne peut
+      pas être exécutée dans le mode parallèle. La présence d'une fonction de
+      ce type dans une requête SQL force un plan d'exécution en série. C'est
+      la valeur par défaut. <literal>PARALLEL RESTRICTED</literal> indique
+      que la fonction peut être exécutée en mode parallèle mais l'exécution
+      est restreinte au processus principal d'exécution. <literal>PARALLEL
+      SAFE</literal> indique que la fonction s'exécute correctement dans le
+      mode parallèle sans restriction.
+     </para>
+
+     <para>
+      Les fonctions doivent être marquées comme non parallélisable si elles
+      modifient l'état d'une base ou si elles font des changements sur la
+      transaction telles que l'utilisation de sous-transactions ou si elles
+      accèdent à des séquences ou tentent de faire des modifications
+      persistentes aux configurations (par exemple
+      <literal>setval</literal>). Elles doivent être marquées comme restreintes
+      au parallélisme si elles accèdent aux tables temporaires, à l'état de
+      connexion des clients, aux curseurs, aux requêtes préparées ou à un
+      état local du moteur où le système ne peut pas synchroniser en mode
+      parallèle (par exemple, <literal>setseed</literal> ne peut pas être
+      exécuté autrement que par le processus principal car une modification
+      réalisée par un autre processus ne pourrait pas être reflété dans le
+      processus principal). En général, si une fonction est marquée sûre à 
+      la parallélisation alors qu'elle est restreinte ou non parallélisable
+      ou si elle est marquée restreinte quand elle est en fait non
+      parallélisable, elle pourrait renvoyer des erreurs ou fournir de mauvaises
+      réponses lorsqu'elle est utilisée dans une requête parallèle. Les
+      fonctions en langage C peuvent en théorie afficher un comportement
+      indéfini si elles sont marquées de façon erronée car le système ne peut
+      pas se protéger comme du code C arbitraire mais, généralement, le
+      résultat ne sera pas pire que pour toute autre fonction. En cas de doute,
+      les fonctions doivent être marqiées comme <literal>UNSAFE</literal>, ce qui
+      correspond à la valeur par défaut.
      </para>
     </listitem>
    </varlistentry>

postgresql/ref/pg_restore.xml

@@ -414,37 +414,39 @@
      <term><option>--table=<replaceable class="parameter">table</replaceable></option></term>
      <listitem>
       <para>
-        Restore definition and/or data of only the named table.
-        For this purpose, <quote>table</quote> includes views, materialized views,
-        sequences, and foreign tables.  Multiple tables
-        can be selected by writing multiple <option>-t</option> switches.
-        This option can be combined with the <option>-n</option> option to
-        specify table(s) in a particular schema.
+        Restaure la définition et/ou les données de la table nommée uniquement.
+        Dans ce cadre, <quote>table</quote> inclut les vues, les vues
+        matérialisées, les séquences et les tables distantes. Plusieurs tables
+        peuvent être sélectionnées en ajoutant plusieurs options
+        <option>-t</option>. Cette option peut être combinée avec l'option
+        <option>-n</option> pour indiquer les tables d'un schéma particulier.
        </para>
 
        <note>
         <para>
-         When <option>-t</option> is specified, <application>pg_restore</application>
-         makes no attempt to restore any other database objects that the
-         selected table(s) might depend upon.  Therefore, there is no
-         guarantee that a specific-table restore into a clean database will
-         succeed.
+         Quand l'option <option>-t</option> est indiquée,
+         <application>pg_restore</application> ne tente pas de restaurer les
+         autres objets de la base de données qui pourraient être liés à la
+         table sélectionnée. De ce fait, il n'y a aucune garantie qu'une
+         restauration d'une table spécifique dans une base propre réussira.
         </para>
        </note>
 
        <note>
         <para>
-         This flag does not behave identically to the <option>-t</option>
-         flag of <application>pg_dump</application>.  There is not currently
-         any provision for wild-card matching in <application>pg_restore</application>,
-         nor can you include a schema name within its <option>-t</option>.
+         Cette option ne se comporte pas de la même façon que l'option
+         <option>-t</option> de <application>pg_dump</application>. Il n'existe
+         pas actuellement de support pour la recherche de motifs dans
+         <application>pg_restore</application>. De plus, vous ne pouvez pas
+         inclure un nom de schéma dans <option>-t</option>.
         </para>
        </note>
 
        <note>
         <para>
-         In versions prior to <productname>PostgreSQL</productname> 9.6, this flag
-         matched only tables, not any other type of relation.
+         Dans les versions de <productname>PostgreSQL</productname> antérieures
+         à la 9.6, Cette option correspondant seulement aux tables, pas aux
+         autres types de relation.
         </para>
        </note>
       </listitem>
@@ -454,8 +456,9 @@
       <term><option>--strict-names</option></term>
       <listitem>
        <para>
-        Require that each schema (-n / --schema) and table (-t / --table)
-        qualifier match at least one schema/table in the backup file.
+        Requiert que chaque qualificateur de schéma (-n / --schema) et table
+        (-t / --table) correspond à au moins un schéma/table dan le fichier
+        de sauvegarde.
       </para>
      </listitem>
     </varlistentry>