Uniformisation du nommage des protocoles Query Simple/Extended

On emploie systématiquement les termes anglais Simple Query ou Extended
Query pour désigner les protocoles.

postgresql/protocol.xml

@@ -83,10 +83,10 @@
 
   <para>
    En mode opérationnel normal, les commandes SQL peuvent être exécutées
-   via deux sous-protocoles. Dans le protocole des <quote>requêtes simples</quote>,
+   via deux sous-protocoles. Dans le protocole <quote>Simple Query</quote>,
    le client envoie juste une chaîne, la requête, qui est analysée et exécutée
-   immédiatement par le serveur. Dans le protocole des <quote>requêtes
-    étendues</quote>, le traitement des requêtes est découpé en de nombreuses
+   immédiatement par le serveur. Dans le protocole <quote>Extended Query</quote>,
+   le traitement des requêtes est découpé en de nombreuses
    étapes&nbsp;: l'analyse, le lien avec les valeurs de paramètres et
    l'exécution. Ceci offre flexibilité et gains en performances
    au prix d'une complexité supplémentaire.
@@ -132,10 +132,10 @@
   </sect2>
 
   <sect2 id="protocol-query-concepts">
-   <title>Aperçu des requêtes étendues</title>
+   <title>Aperçu du protocole Extended Query</title>
 
    <para>
-    Dans le protocole des requêtes étendues, l'exécution de commandes SQL est
+    Dans le protocole Extended Query, l'exécution de commandes SQL est
     scindée en plusieurs étapes. L'état retenu entre les étapes est représenté
     par deux types d'objets&nbsp;: les <firstterm>instructions préparées</firstterm> et
     les <firstterm>portails</firstterm>. Une instruction préparée représente le résultat
@@ -531,10 +531,10 @@
   </sect2>
 
   <sect2>
-   <title>Requête simple</title>
+   <title>Protocole Simple Query</title>
 
    <para>
-    Un cycle de requête simple est initié par le client qui envoie un message
+    En protocole Simple Query, un cycle est initié par le client qui envoie un message
     Query au serveur. Le message inclut une commande SQL (ou plusieurs) exprimée
     comme une chaîne texte. Le serveur envoie, alors, un ou plusieurs messages
     de réponse dépendant du contenu de la chaîne représentant la requête et
@@ -678,7 +678,7 @@
    </para>
 
    <para>
-    En mode de requêtage simple, les valeurs récupérées sont toujours au format
+    En mode Simple Query, les valeurs récupérées sont toujours au format
     texte, sauf si la commande est un <command>fetch</command> sur un curseur déclaré
     avec l'option <literal>binary</literal>. Dans ce cas, les valeurs récupérées sont
     au format binaire. Les codes de format donnés dans le message RowDescription
@@ -701,10 +701,10 @@
   </sect2>
 
   <sect2 id="protocol-flow-ext-query">
-   <title>Requête étendue</title>
+   <title>Protocole Extended Query</title>
 
    <para>
-    Le protocole de requête étendu divise le protocole de requêtage simple décrit
+    Le protocole Extended Query divise le protocole Simple Query décrit
     ci-dessus en plusieurs étapes. Les résultats des étapes de préparation
     peuvent être réutilisés plusieurs fois pour plus d'efficacité. De plus,
     des fonctionnalités supplémentaires sont disponibles, telles que la
@@ -748,7 +748,7 @@
     <para>
      La chaîne contenue dans un message Parse ne peut pas inclure plus d'une
      instruction SQL, sinon une erreur de syntaxe est rapportée. Cette
-     restriction n'existe pas dans le protocole de requête simple, mais est
+     restriction n'existe pas dans le protocole Simple Query, mais est
      présente dans le protocole étendu. En effet, permettre aux instructions
      préparées ou aux portails de contenir de multiples commandes compliquerait
      inutilement le protocole.
@@ -760,7 +760,7 @@
     jusqu'à la fin de la session courante, sauf si elle est détruite
     explicitement. Une instruction préparée non nommée ne dure que jusqu'à
     la prochaine instruction Parse spécifiant l'instruction non nommée comme
-    destination. Un simple message Query détruit également l'instruction non
+    destination. Un message Simple Query détruit également l'instruction non
     nommée. Les instructions préparées nommées doivent être explicitement
     closes avant de pouvoir être redéfinies par un autre message Parse. Ce n'est
     pas obligatoire pour une instruction non nommée. Il est également possible
@@ -789,7 +789,7 @@
      Le choix entre sortie texte et binaire est déterminé par les codes
      de format donnés dans Bind, quelle que soit la commande SQL impliquée.
      L'attribut <literal>BINARY</literal> dans les déclarations du curseur n'est pas
-     pertinent lors de l'utilisation du protocole de requête étendue.
+     pertinent lors de l'utilisation du protocole Extended Query.
     </para>
    </note>
 
@@ -809,7 +809,7 @@
     de la transaction courante sauf s'il est explicitement détruit. Un
     portail non nommé est détruit à la fin de la transaction ou dès la prochaine
     instruction Bind spécifiant le portail non nommé comme destination.
-    Un simple message Query détruit également le portail non nommé. Les
+    (À noter qu'un message Simple Query détruit également le portail non nommé.) Les
     portails nommés doivent être explicitement fermés avant de pouvoir être
     redéfinis par un autre message Bind. Cela n'est pas obligatoire pour le portail non
     nommé. Il est également possible de créer des portails nommés, et d'y
@@ -826,8 +826,8 @@
     qui renvoient des ensembles de lignes&nbsp;; dans les autres cas, la
     commande est toujours exécutée jusqu'à la fin et le nombre de lignes est
     ignoré. Les réponses possibles d'Execute sont les mêmes que celles
-    décrites ci-dessus pour les requêtes lancées via le protocole de requête
-    simple, si ce n'est qu'Execute ne cause pas l'envoi de ReadyForQuery ou de
+    décrites ci-dessus pour les requêtes lancées via le protocole Simple
+    Query, si ce n'est qu'Execute ne cause pas l'envoi de ReadyForQuery ou de
     RowDescription.
    </para>
 
@@ -844,14 +844,14 @@
    </para>
 
    <para>
-    À la réalisation complète de chaque série de messages de requêtes étendues,
+    À la réalisation complète de chaque série de messages Extended Query,
     le client doit lancer un message Sync. Ce message sans paramètre oblige
     le serveur à fermer la transaction courante si elle n'est pas à l'intérieur
     d'un bloc de transaction <command>begin</command>/<command>commit</command>
     (<quote>fermer</quote> signifiant valider en l'absence d'erreur ou annuler sinon).
     Une réponse ReadyForQuery est alors envoyée. Le but de Sync est de fournir
     un point de resynchronisation pour les récupérations d'erreurs. Quand une
-    erreur est détectée lors du traitement d'un message de requête étendue, le
+    erreur est détectée lors du traitement d'un message Extended Query, le
     serveur lance ErrorResponse, puis lit et annule les messages jusqu'à ce
     qu'un Sync soit atteint. Il envoie ensuite ReadyForQuery et retourne au
     traitement normal des messages. Aucun échappement n'est réalisé si une erreur
@@ -869,7 +869,7 @@
 
    <para>
     En plus de ces opérations fondamentales, requises, il y a plusieurs opérations
-    optionnelles qui peuvent être utilisées avec le protocole de requête étendue.
+    optionnelles qui peuvent être utilisées avec le protocole Extended Query.
    </para>
 
    <para>
@@ -916,7 +916,7 @@
    <para>
     Le message Flush n'engendre pas de sortie spécifique, mais
     force le serveur à délivrer toute donnée restante dans les tampons de
-    sortie. Un Flush doit être envoyé après toute commande de requête étendue,
+    sortie. Un Flush doit être envoyé après toute commande Extended Query,
     à l'exception de Sync, si le client souhaite examiner le résultat de cette
     commande avant de lancer d'autres commandes. Sans Flush, les messages
     retournés par le serveur seront combinés en un nombre minimum de paquets
@@ -925,7 +925,7 @@
 
    <note>
     <para>
-     Le message Query simple est approximativement équivalent à la séquence Parse,
+     Le message Simple Query est approximativement équivalent à la séquence Parse,
      Bind, Describe sur un portail, Execute, Close, Sync utilisant les
      objets de l'instruction préparée ou du portail, non nommés et sans
      paramètres. Une différence est l'acceptation de plusieurs instructions SQL
@@ -1037,19 +1037,19 @@
     message CopyDone (permettant une fin avec succès) ou un message CopyFail
     (qui causera l'échec de l'instruction SQL <command>copy</command> avec une erreur).
     Le serveur retourne alors au mode de traitement de la commande précédant le
-    début de <command>copy</command>, protocole de requête simple ou étendu. Il
+    début de <command>copy</command>, soit les protocoles Simple Query ou Extended Query. Il
     enverra enfin CommandComplete (en cas de succès) ou ErrorResponse (sinon).
    </para>
 
    <para>
     Si le serveur détecte une erreur en mode copy-in (ce qui inclut la
     réception d'un message CopyFail), il enverra un message ErrorResponse.
-    Si la commande <command>copy</command> a été lancée à l'aide d'un message de
-    requête étendue, le serveur annulera les messages du client jusqu'à
+    Si la commande <command>copy</command> a été lancée à l'aide d'un message
+    Extended Query, le serveur annulera les messages du client jusqu'à
     ce qu'un message Sync soit reçu. Il enverra alors un message ReadyForQuery
     et retournera dans le mode de fonctionnement normal. Si la commande
     <command>copy</command> a été lancée dans un message
-    simple Query, le reste de ce message est annulé et ReadyForQuery est envoyé.
+    Simple Query, le reste de ce message est annulé et ReadyForQuery est envoyé.
     Dans tous les cas, les messages CopyData, CopyDone ou CopyFail suivants
     envoyés par l'interface seront simplement annulés.
    </para>
@@ -6797,7 +6797,7 @@ TupleData
   </para>
 
   <para>
-   Il existe un nouveau sous-protocole pour les <quote>requêtes étendues</quote> qui
+   Il existe un nouveau sous-protocole <quote>Extended Query</quote> qui
    ajoute les types de messages client Parse, Bind, Execute, Describe, Close,
    Flush et Sync et les types de messages serveur ParseComplete, BindComplete,
    PortalSuspended, ParameterDescription, NoData et CloseComplete. Les clients