Skip to content

Commit

Permalink
Corrections de typo et orthographe dans le chapitre "protocole"
Browse files Browse the repository at this point in the history
  • Loading branch information
@dlax
dlax committed Nov 19, 2020
1 parent ee8cd87 commit ef1efdf
Showing 1 changed file with 39 additions and 39 deletions.
78 changes: 39 additions & 39 deletions postgresql/protocol.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,9 +19,9 @@

<para>
Ce document décrit la version 3.0 de ce protocole, telle qu'implantée dans
<productname>postgresql</productname> depuis la version 7.4. pour obtenir la
<productname>postgresql</productname> depuis la version 7.4. Pour obtenir la
description des versions précédentes du protocole, il faudra se reporter aux
versions antérieures de la documentation de <productname>postgresql</productname>. un
versions antérieures de la documentation de <productname>postgresql</productname>. Un
même serveur peut prendre en charge plusieurs versions du protocole. Lors de l'établissement
de la communication, le client indique au serveur la version du protocole qu'il
souhaite utiliser. Si la version majeure demandée par le client n'est pas
Expand Down Expand Up @@ -140,9 +140,9 @@
<firstterm>paramètres</firstterm>. Un portail représente une instruction prête à être
exécutée ou déjà partiellement exécutée, dont toutes les valeurs de
paramètres manquants sont données (pour les instructions
<command>select</command>, un portail est équivalent à un curseur ouvert. il est
<command>select</command>, un portail est équivalent à un curseur ouvert. Il est
choisi d'utiliser un terme différent, car les curseurs ne gèrent pas les
instructions autres que <command>select</command>)
instructions autres que <command>select</command>).
</para>

<para>
Expand Down Expand Up @@ -178,7 +178,7 @@
différents <firstterm>formats</firstterm>. Depuis <productname>PostgreSQL</productname> 7.4, les
seuls formats supportés sont le <quote>texte</quote> et le <quote>binaire</quote> mais
le protocole prévoit des extensions futures. Le format souhaité pour toute valeur
est spécifié par un <firstterm>code de format</firstterm>. les clients peuvent spécifier
est spécifié par un <firstterm>code de format</firstterm>. Les clients peuvent spécifier
un code de format pour chaque valeur de paramètre transmise et pour chaque
colonne du résultat d'une requête. Une donnée de type texte a comme code
de format zéro (0) et une donnée de type binaire a comme code de format un (1).
Expand Down Expand Up @@ -212,7 +212,7 @@
<para>
Cette section décrit le flux des messages et la sémantique de chaque type
de message (les détails concernant la représentation exacte de chaque message
apparaissent dans <xref linkend="protocol-message-formats"/>). il existe
apparaissent dans <xref linkend="protocol-message-formats"/>). Il existe
différents sous-protocoles en fonction de l'état de la connexion&nbsp;: lancement,
requête, appel de fonction, COPY et clôture. Il existe aussi des provisions
spéciales pour les opérations asynchrones (incluant les
Expand Down Expand Up @@ -241,9 +241,9 @@
d'authentification adapté (tel un mot de passe). Pour toutes les méthodes
d'authentification, sauf GSSAPI, SSPI et SASL, il y a au maximum une requête et
une réponse. Avec certaines méthodes, aucune réponse du client n'est
nécessaire&nbsp; aucune demande d'authentification n'est alors effectuée.
nécessaire, et aucune demande d'authentification n'est alors effectuée.
Pour GSSAPI, SSPI et SASL, plusieurs échanges de paquets peuvent être
nécessaire pour terminer l'authentification.
nécessaires pour terminer l'authentification.
</para>

<para>
Expand Down Expand Up @@ -443,7 +443,7 @@
Après la réception du message AuthenticationOk, le client attend d'autres
messages du serveur. Au cours de cette phase, un processus serveur est lancé
et le client est simplement en attente. Il est encore possible que la tentative de
lancement échoue (ErrorResponse) ou que le serveur décline le supporte de
lancement échoue (ErrorResponse) ou que le serveur décline le support de
la version mineure du protocole demandée (NegotiateProtocolVersion) mais,
dans la plupart des cas, le serveur enverra les messages ParameterStatus,
BackendKeyData et enfin ReadyForQuery.
Expand Down Expand Up @@ -478,9 +478,9 @@
<para>
Ce message informe le client de la configuration actuelle (initiale)
des paramètres du serveur, tels <varname>client_encoding</varname> ou
<varname>datestyle</varname>. le client peut ignorer ce message ou enregistrer
<varname>datestyle</varname>. Le client peut ignorer ce message ou enregistrer
la configuration pour ses besoins futurs&nbsp;; voir
<xref linkend="protocol-async"/> pour plus de détails. le client ne
<xref linkend="protocol-async"/> pour plus de détails. Le client ne
devrait pas répondre à ce message mais continuer à attendre un message
ReadyForQuery.
</para>
Expand Down Expand Up @@ -558,7 +558,7 @@
<term>copyinresponse</term>
<listitem>
<para>
Le serveur est prêt à copier des données du client vers une table&nbsp;
Le serveur est prêt à copier des données du client vers une table&nbsp;;
voir <xref linkend="protocol-copy"/>.
</para>
</listitem>
Expand Down Expand Up @@ -676,7 +676,7 @@
<para>
En mode de requêtage simple, 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
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
indiquent le format utilisé.
</para>
Expand Down Expand Up @@ -742,7 +742,7 @@

<para>
Lorsqu'un simple message de requête contient plus d'une instruction SQL
(séparés par des points-virgules), ces instructions sont exécutés comme une
(séparées par des points-virgules), ces instructions sont exécutées comme une
seule transaction à moins que des commandes explicites de contrôle des
transactions ne soient incluses pour forcer un comportement différent.
Par exemple, si le message contient&nbsp;:
Expand All @@ -766,7 +766,7 @@ COMMIT;
INSERT INTO mytable VALUES(2);
SELECT 1/0;
</programlisting>
Alors le premier <command>INSERT</command> est validée par la commande
Alors le premier <command>INSERT</command> est validé par la commande
<command>COMMIT</command> explicite. Le second <command>INSERT</command>
et le <command>SELECT</command> sont toujours traités comme une seule
transaction, de sorte que l'échec de la division par zéro fera annuler
Expand Down Expand Up @@ -800,7 +800,7 @@ SELECT 1/0;
de transaction normal qui ne sera terminé que par un <command>COMMIT</command>
ou un <command>ROLLBACK</command> explicite&nbsp;; que celui-ci apparaisse dans
ce message de requête ou dans un autre. Si le <command>BEGIN</command>
suit certaines instructions qui ont été exécutés comme un bloc de transaction
suit certaines instructions qui ont été exécutées comme un bloc de transaction
implicite, ces instructions ne sont pas immédiatement validées&nbsp;; en fait,
ils sont inclus rétroactivement dans le nouveau bloc de transaction normal.
</para>
Expand All @@ -824,7 +824,7 @@ SELECT 1/0;
<para>
N'oubliez pas que, quelle que soit la commande de contrôle de transaction
présente, l'exécution du message de requête s'arrête dès la première erreur.
Par exemple, si pour un message de requête unique l'on donne&nbsp;:
Par exemple, si pour un message de requête simple l'on donne&nbsp;:
<programlisting>
BEGIN;
SELECT 1/0;
Expand Down Expand Up @@ -894,7 +894,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
à O, ou en créant un tableau d'OID de type plus court que le nombre de
paramètres (<literal>$</literal><replaceable>n</replaceable>) utilisés
dans la chaîne de requête.
Un autre cas spécial est d'utiliser <type>void</type> comme type de
Un autre cas particulier est d'utiliser <type>void</type> comme type de
paramètre (c'est à dire l'OID du pseudo-type <type>void</type>). Cela
permet d'utiliser des paramètres dans des fonctions en tant qu'argument
OUT.
Expand Down Expand Up @@ -949,21 +949,21 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
<note>
<para>
Le choix entre sortie texte et binaire est déterminé par les codes
de format donnés dans Bind, quel que soit la commande SQL impliquée.
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.
</para>
</note>

<para>
La planification de la requête survient généralement quand le message
Bind est traité. Si la requête préparée n'a pas de paramètres ou
Bind est traité. Si la requête préparée n'a pas de paramètre ou
si elle est exécutée de façon répétée, le serveur peut sauvegarder le
plan créé et le ré-utiliser lors des appels suivants à Bind pour la
même requête préparée. Néanmoins, il ne le fera que s'il estime qu'un
plan générique peut être créé en étant pratiquement aussi efficace
qu'un plan dépendant des valeurs des paramètres. Cela arrive de façon
transparente en ce qui concerne le protocole
transparente en ce qui concerne le protocole.
</para>

<para>
Expand All @@ -983,11 +983,11 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
Dès lors qu'un portail existe, il peut être exécuté à l'aide d'un message
Execute. Ce message spécifie le nom du portail (une chaîne vide désigne le
portail non nommé) et un nombre maximum de lignes de résultat (zéro
signifiant la <quote>récupération de toutes les lignes</quote>). le nombre de lignes
signifiant la <quote>récupération de toutes les lignes</quote>). Le nombre de lignes
de résultat a seulement un sens pour les portails contenant des commandes
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ême que celles
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
RowDescription.
Expand Down Expand Up @@ -1017,14 +1017,14 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
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
est détectée <emphasis>lors</emphasis> du traitement de sync &mdash; l'unicité du
est détectée <emphasis>lors</emphasis> du traitement de Sync &mdash; l'unicité du
ReadyForQuery envoyé pour chaque Sync est ainsi assurée.
</para>

<note>
<para>
Sync n'impose pas la fermeture d'un bloc de transactions ouvert avec
<command>begin</command>. cette situation est détectable car le message
<command>begin</command>. Cette situation est détectable car le message
ReadyForQuery inclut le statut de la transaction.
</para>
</note>
Expand All @@ -1039,7 +1039,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
existant (ou une chaîne vide pour le portail non nommé). La réponse est un
message RowDescription décrivant les lignes qui seront renvoyées par
l'exécution du portail&nbsp;; ou un message NoData si le portail ne contient
pas de requête renvoyant des lignes&nbsp;; ou ErrorResponse le portail
pas de requête renvoyant des lignes&nbsp;; ou ErrorResponse si le portail
n'existe pas.
</para>

Expand Down Expand Up @@ -1087,7 +1087,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->

<note>
<para>
Le message Query simple est approximativement équivalent aux séries Parse,
Le message Query simple 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
Expand All @@ -1114,7 +1114,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
Le sous-protocole d'appel de fonction est une fonctionnalité qu'il vaudrait
probablement mieux éviter dans tout nouveau code. Des résultats similaires
peuvent être obtenus en initialisant une instruction préparée qui lance
<literal>select function($1, ...)</literal>. le cycle de l'appel de fonction peut
<literal>select function($1, ...)</literal>. Le cycle de l'appel de fonction peut
alors être remplacé par Bind/Execute.
</para>
</note>
Expand Down Expand Up @@ -1190,7 +1190,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->

<para>
Le mode Copy-in (transfert de données vers le serveur) est initié quand le
serveur exécute une instruction SQL <command>copy from stdin</command>. le serveur
serveur exécute une instruction SQL <command>copy from stdin</command>. Le serveur
envoie une message CopyInResponse au client. Le client peut alors envoyer
zéro (ou plusieurs) message(s) CopyData, formant un flux de données en
entrée (il n'est pas nécessaire que les limites du message aient un
Expand All @@ -1199,12 +1199,12 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
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>, protocole de requête simple ou étendu. Il
enverra enfin CommandComplete (en cas de succès) ou ErrorResponse (sinon).
</para>

<para>
Si le serveur détecte un erreur en mode copy-in (ce qui inclut la
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'à
Expand Down Expand Up @@ -1313,11 +1313,11 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
Des messages ParameterStatus seront engendrés à chaque fois que la valeur
active d'un paramètre est modifiée, et cela pour tout paramètre que le
serveur pense utile au client. Cela survient plus généralement en réponse à
une commande SQL <command>set</command> exécutée par le client. ce cas est en fait
une commande SQL <command>set</command> exécutée par le client. Ce cas est en fait
synchrone &mdash; mais il est possible aussi que le changement de statut d'un
paramètre survienne à la suite d'une modification par l'administrateur des
fichiers de configuration&nbsp;; changements suivis de l'envoi du signal
<systemitem>sighup</systemitem> au postmaster. de plus, si une commande set
<systemitem>sighup</systemitem> au postmaster. De plus, si une commande set
est annulée, un message ParameterStatus approprié sera engendré pour
rapporter la valeur effective.
</para>
Expand Down Expand Up @@ -1494,9 +1494,9 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
Le client peut alors clore la connexion s'il n'est pas satisfait de la
réponse. Pour continuer après un <literal>s</literal>, il faut échanger une poignée
de main <acronym>ssl</acronym> (handshake) (non décrite ici car faisant partie de
la spécification <acronym>ssl</acronym>) avec le serveur. en cas de succès, le
la spécification <acronym>ssl</acronym>) avec le serveur. En cas de succès, le
StartupMessage habituel est envoyé. Dans ce cas, StartupMessage et toutes
les données suivantes seront chiffrées avec <acronym>ssl</acronym>. pour continuer
les données suivantes seront chiffrées avec <acronym>ssl</acronym>. Pour continuer
après un <literal>n</literal>, il suffit d'envoyer le startupmessage habituel et
de continuer sans chiffrage.
</para>
Expand Down Expand Up @@ -1788,7 +1788,7 @@ SELCT 1/0;<!-- l'erreur est intentionnelle -->
</term>
<listitem>
<para>
Exactement <replaceable>n</replaceable> octets. si la largeur
Exactement <replaceable>n</replaceable> octets. Si la largeur
<replaceable>n</replaceable> du champ n'est pas une constante,
elle peut toujours être déterminée à partir d'un champ précédent
du message. Si <replaceable>c</replaceable> est spécifié, c'est
Expand Down Expand Up @@ -3806,7 +3806,7 @@ Bind (F)
<listitem>
<para>
Nombre de codes de format des colonnes de résultat qui
suivent (noté <replaceable>r</replaceable> ci-dessous). peut valoir zéro
suivent (noté <replaceable>r</replaceable> ci-dessous). Peut valoir zéro
pour indiquer qu'il n'y a pas de colonnes de résultat ou que les
colonnes de résultat utilisent le format par défaut
(texte)&nbsp;; ou une, auquel cas le code de format spécifié est
Expand Down Expand Up @@ -4143,7 +4143,7 @@ Bind (F)
<listitem>
<para>
Données formant une partie d'un flux de données
<command>copy</command>. les messages envoyés depuis le serveur
<command>copy</command>. Les messages envoyés depuis le serveur
correspondront toujours à des lignes uniques de données, mais
les messages envoyés par les clients peuvent diviser le flux de
données de façon arbitraire.
Expand Down Expand Up @@ -6228,7 +6228,7 @@ Bind (F)
<listitem>
<para>
Code&nbsp;: code SQLSTATE de l'erreur (voir
<xref linkend="errcodes-appendix"/>). non internationalisable.
<xref linkend="errcodes-appendix"/>). Non internationalisable.
Toujours présent.
</para>
</listitem>
Expand Down

0 comments on commit ef1efdf

Please sign in to comment.