Mise à jour en version 10.22

postgresql/client-auth.xml

@@ -382,7 +382,10 @@ hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>
       <para>
        Indique la méthode d'authentification à utiliser lors d'une
        connexion via cet enregistrement. Les choix possibles sont résumés ici&nbsp;; les
-       détails se trouvent dans la <xref linkend="auth-methods"/>.
+       détails se trouvent dans la <xref linkend="auth-methods"/>. Toutes les options
+       sont en minuscules et traitées avec une sensibilité à la casse, donc
+       même les acronymes comme <literal>ldap</literal> doivent être écrits
+       en minuscule.
 
        <variablelist>
         <varlistentry>

postgresql/config.xml

@@ -6070,8 +6070,10 @@ COPY postgres_log FROM '/chemin/complet/vers/le/logfile.csv' WITH csv;
      dans chaque session, avec l'heure de démarrage de la commande. Ce paramètre
      est activé par défaut. Même si le paramètre est activé, cette information
      n'est pas visible par tous les utilisateurs, mais uniquement par les
-     superutilisateurs et l'utilisateur possédant la session
-     traitée ; de ce fait, cela ne représente pas une faille de
+     superutilisateurs, les rôles dotés des droits du rôle
+     <literal>pg_read_all_stats</literal> et l'utilisateur possédant la session
+     traitée (ceci incluant les sessions appartenant à un rôle sur lequel ils
+     ont des droits)&nbsp;; de ce fait, cela ne représente pas une faille de
      sécurité. Seuls les superutilisateurs peuvent modifier ce paramètre.
     </para>
    </listitem>
@@ -8622,6 +8624,27 @@ SET XML OPTION { DOCUMENT | CONTENT };
    </para>
 
    <variablelist>
+    <varlistentry id="guc-allow-in-place-tablespaces" xreflabel="allow_in_place_tablespaces">
+     <term><varname>allow_in_place_tablespaces</varname> (<type>boolean</type>)
+     <indexterm>
+       <primary>paramètre de configuration <varname>allow_in_place_tablespaces</varname></primary>
+     </indexterm>
+     </term>
+     <listitem>
+      <para>
+       Autorise la création des tablespaces dans des répertoires situés à
+       l'intérieur de <filename>pg_tblspc</filename>, quand une chaîne
+       d'emplacement vide est fournie à la commande <command>CREATE
+       TABLESPACE</command>. Ceci a pour but de permettre de tester des
+       scénarios de réplication où le primaire et le secondaire sont exécutés
+       sur la même machine. Ces répertoires pourraient poser problème aux outils
+       de sauvegarde qui s'attendent à trouver uniquement des liens symboliques
+       à cet emplacement. Seuls les superutilisateurs peuvent modifier ce
+       paramètre.
+      </para>
+     </listitem>
+    </varlistentry>
+
     <varlistentry id="guc-allow-system-table-mods" xreflabel="allow_system_table_mods">
      <term><varname>allow_system_table_mods</varname> (<type>boolean</type>)</term>
      <listitem>

postgresql/datatype.xml

@@ -3855,10 +3855,11 @@ opposition de deux choses -->
          Le standard IEEE 802-2001 spécifie la seconde forme affichée
          (avec les tirets) comme forme canonique pour les adresses MAC, et
          la première forme (avec les :) comme la notation à bits retournés,
-         ce qui donne l'équivalence 08-00-2b-01-02-03 = 01:00:4D:08:04:0C.
+         MSB en premier,
+         ce qui donne l'équivalence 08-00-2b-01-02-03 = 10:00:D4:80:40:C0.
          Cette convention est largement ignorée aujourd'hui et n'a de
          sens que pour des protocoles réseau obsolètes (comme Token Ring).
-         PostgreSQL ne tient pas compte des bits retournés, et tous les formats
+         PostgreSQL ne tient pas compte des bits retournés ; tous les formats
          acceptés utilisent l'ordre canonique LSB.
         </para>
 

postgresql/extend.xml

@@ -1089,17 +1089,6 @@ SELECT * FROM pg_extension_update_paths('<replaceable>extension_name</replaceabl
      <varname>search_path</varname> d'installation. Néanmoins, aucun mécanisme
      n'existe actuellement pour forcer cela.
     </para>
-
-    <para>
-     N'utilisez <emphasis>pas</emphasis> <command>CREATE OR REPLACE
-      FUNCTION</command>, sauf dans un script de mise à jour qui doit modifier
-     la définition d'une fonction connue en tant que membre de l'extension.
-     (Et de la même façon pour l'option <literal>OR REPLACE</literal> d'autres
-     types d'objet.) Utiliser <literal>OR REPLACE</literal> sans raison ajoute
-     un risque d'écraser accidentellement la fonction de quelqu'un d'autre,
-     mais crée un risque de sécurité puisque la fonction surchargée conservera
-     son propriétaire original, qui pourrait la modifier de nouveau.
-    </para>
    </sect3>
   </sect2>
 

postgresql/install-windows.xml

@@ -545,15 +545,6 @@ $ENV{MSBFLAGS}="/m";
      </para></listitem>
     </varlistentry>
 
-    <varlistentry>
-     <term><varname>LZ4</varname></term>
-     <listitem><para>
-      Chemin vers une commande <application>lz4</application>. La valeur par
-      défaut est <literal>lz4</literal>, qui serait la commande trouvée dans le
-      <varname>PATH</varname>.
-     </para></listitem>
-    </varlistentry>
-
     <varlistentry>
      <term><varname>TAR</varname></term>
      <listitem><para>

postgresql/libpq.xml

@@ -6785,9 +6785,11 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
        <primary><envar>PGSERVICEFILE</envar></primary>
       </indexterm>
       <envar>PGSERVICEFILE</envar> indique le nom du fichier service de
-      connexion par utilisateur. S'il n'est pas configuré, sa valeur par
-      défaut est <filename>~/.pg_service.conf</filename>
+      connexion par utilisateur.
       (voir <xref linkend="libpq-pgservice"/>).
+      Il vaut par défaut <filename>~/.pg_service.conf</filename>, ou
+      <filename>%APPDATA%\postgresql\.pg_service.conf</filename> sur
+      Microsoft Windows.
      </para>
     </listitem>
 
@@ -7057,7 +7059,7 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
    Sur Microsoft Windows, le fichier est nommé
    <filename>%APPDATA%\postgresql\pgpass.conf</filename> (où <filename>%APPDATA%</filename>
    fait référence au sous-répertoire Application Data du profile de l'utilisateur).
-   De manière alternative, un fichier de mots de passe peut être spécifié en
+   De manière alternative, le fichier de mots de passe peut être spécifié en
    utilisant le paramètre de connexion <xref linkend="libpq-connect-passfile"/>
    ou la variable d'environnement <envar>PGPASSFILE</envar>.
   </para>
@@ -7114,21 +7116,29 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
   <para>
    Le fichier des connexions de service autorise l'association des paramètres de
    connexions avec un seul nom de service. Ce nom de service peut ensuite être
-   spécifié par une connexion libpq et les paramétrages associés seront utilisés.
+   spécifié par une chaîne de connexion libpq et les paramétrages associés seront utilisés.
    Ceci permet de modifier les paramètres de connexion sans avoir à recompiler
-   l'application libpq. Le nom de service peut aussi être spécifié en utilisant
+   l'application utilisant la libpq. Le nom de service peut aussi être spécifié en utilisant
    la variable d'environnement <envar>PGSERVICE</envar>.
   </para>
 
   <para>
-   Le fichier de service pour la connexion peut être un fichier par utilisateur
-   sur <filename>~/.pg_service.conf</filename> ou à l'emplacement indiqué par
-   la variable d'environnement <envar>PGSERVICEFILE</envar>. Il peut aussi être
-   un fichier global au système dans le répertoire
-   <filename>`pg_config --sysconfdir`/pg_service.conf</filename> ou dans le répertoire indiqué par
-   la variable d'environnement <envar>PGSYSCONFDIR</envar>. Si les définitions
-   de service de même nom existent dans le fichier utilisateur et système,
-   le fichier utilisateur est utilisé.
+   Les noms de service peuvent être définis soit dans le fichier service par
+   utilisateur soit dans un fichier global du système. Si le même nom de service
+   existe dans le fichier utilisateur et le fichier global, le fichier
+   utilisateur a priorité. Par défaut, le fichier service par utilisateur est
+   nommé <filename>~/.pg_service.conf</filename>.  Sur Microsoft Windows, il est
+   nommé <filename>%APPDATA%\postgresql\.pg_service.conf</filename> (où
+   <filename>%APPDATA%</filename> fait référence au sous-répertoire Application
+   Data dans le profile utilisateur). Un nom de fichier différent peut être
+   indiqué en configurant la variable d'environnement
+   <envar>PGSERVICEFILE</envar>.  Le fichier global du système est nommé
+   <filename>pg_service.conf</filename>.  Par défaut, il est recherché dans le
+   répertoire <filename>etc</filename> de l'installation de
+   <productname>PostgreSQL</productname> (utilisez <literal>pg_config
+   --sysconfdir</literal> pour identifier précisément ce répertoire). Un autre
+   répertoire, mais pas un nom de fichier différent, peut être précisé en
+   configurant la variable d'environnement <envar>PGSYSCONFDIR</envar>.
   </para>
 
   <para>
@@ -7142,9 +7152,23 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
     port=5433
     user=admin
    </programlisting>
-   Un fichier exemple est fourni sur
+   Un fichier exemple est fourni dans l'installation de
+   <productname>PostgreSQL</productname> avec
    <filename>share/pg_service.conf.sample</filename>.
   </para>
+
+  <para>
+   Les paramètres de connection obtenus à partir d'un fichier de service sont
+   combinés avec les paramètres obtenus d'autres sources. Une configuration d'un
+   fichier de service surcharge la variable d'environnement correspondante et, à
+   son tour, peut être surchargé par une valeur donnée directement dans la
+   chaîne de connexion. Par exemple, en utilisant le fichier de service
+   ci-dessus, une chaîne de connexion <literal>service=mabase
+   port=5434</literal> utilisera l'hôte <literal>unhote</literal>, le port
+   <literal>5434</literal>, l'utilisateur <literal>admin</literal>, et les
+   autres paramètres tels qu'ils sont configurés par les variables
+   d'environnement ou les valeurs par défaut internes.
+  </para>
  </sect1>
 
  <sect1 id="libpq-ldap">

postgresql/mvcc.xml

@@ -289,12 +289,11 @@
 
   <para>
    Le tableau montre aussi que l'implémentation Repeatable Read de PostgreSQL
-   n'autorise pas les lectures fantômes. Un comportement plus strict est
-   autorisé par le standard SQL&nbsp;: les quatre niveaux d'isolation
-   définissent seulement les phénomènes qui ne doivent pas survenir, et non
-   pas les phénomènes qui <emphasis>doivent</emphasis> survenir. Le
-   comportement des niveaux d'isolation disponibles est détaillé dans les
-   sous-sections suivantes.
+   n'autorise pas les lectures fantômes. Ceci est acceptable pour le standard
+   SQL car le standard spécifie les anomalies qui ne doivent
+   <emphasis>pas</emphasis> survenir pour certains niveaux d'isolation&nbsp;;
+   des garanties plus hautes sont acceptables. Le comportement des niveaux
+   d'isolation disponibles est détaillé dans les sous-sections suivantes.
   </para>
 
   <para>
@@ -918,7 +917,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
     <title>Modes de verrous au niveau table</title>
     <varlistentry>
      <term>
-      <literal>ACCESS SHARE</literal>
+      <literal>ACCESS SHARE</literal> (<literal>AccessShareLock</literal>)
      </term>
      <listitem>
       <para>
@@ -935,7 +934,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>ROW SHARE</literal>
+      <literal>ROW SHARE</literal> (<literal>RowShareLock</literal>)
      </term>
      <listitem>
       <para>
@@ -955,7 +954,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>ROW EXCLUSIVE</literal>
+      <literal>ROW EXCLUSIVE</literal> (<literal>RowExclusiveLock</literal>)
      </term>
      <listitem>
       <para>
@@ -977,7 +976,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>SHARE UPDATE EXCLUSIVE</literal>
+      <literal>SHARE UPDATE EXCLUSIVE</literal> (<literal>ShareUpdateExclusiveLock</literal>)
      </term>
      <listitem>
       <para>
@@ -1002,7 +1001,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>SHARE</literal>
+      <literal>SHARE</literal> (<literal>ShareLock</literal>)
      </term>
      <listitem>
       <para>
@@ -1021,7 +1020,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>SHARE ROW EXCLUSIVE</literal>
+      <literal>SHARE ROW EXCLUSIVE</literal> (<literal>ShareRowExclusiveLock</literal>)
      </term>
      <listitem>
       <para>
@@ -1044,7 +1043,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>EXCLUSIVE</literal>
+      <literal>EXCLUSIVE</literal> (<literal>ExclusiveLock</literal>)
      </term>
      <listitem>
       <para>
@@ -1066,7 +1065,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
 
     <varlistentry>
      <term>
-      <literal>ACCESS EXCLUSIVE</literal>
+      <literal>ACCESS EXCLUSIVE</literal> (<literal>AccessExclusiveLock</literal>)
      </term>
      <listitem>
       <para>

postgresql/protocol.xml

@@ -932,6 +932,65 @@
    </note>
   </sect2>
 
+  <sect2 id="protocol-flow-pipelining">
+   <title>Pipelines</title>
+
+   <indexterm zone="protocol-flow-pipelining">
+    <primary>pipelines</primary>
+    <secondary>spécification du protocole</secondary>
+   </indexterm>
+
+   <para>
+    L'utilisation du protocole de requête étendue autorise les
+    <firstterm>pipelines</firstterm>, autrement dit l'envoi d'une série de
+    requêtes sans attendre que les premières se terminent. Ceci réduit le nombre
+    d'aller/retour réseau nécessaire pour terminer une série d'opérations.
+    Néanmoins, l'utilisateur doit faire attention au comportement souhaité si
+    une des étapes échoue car les requêtes suivantes seront déjà envoyées au
+    serveur.
+   </para>
+
+   <para>
+    Une façon de gérer cela est de transformer la série complète de requête en
+    une seule transaction, donc de l'entourer des commandes
+    <command>BEGIN</command> ...  <command>COMMIT</command>. Cela n'aide
+    cependant pas les personnes qui souhaiteraient que certaines commandes
+    soient validées indépendamment des autres.
+   </para>
+
+   <para>
+    Le protocole de requête étendue fournit un autre moyen pour gérer cette
+    problématique. Il s'agit d'oublier d'envoyer les messages Sync entre les
+    étapes qui sont dépendantes. Comme, après une erreur, le moteur ignorera les
+    messages des commandes jusqu'à ce qu'il trouve un message Sync, cela
+    autorise les commandes ultérieures d'un pipeline d'être automatiquement
+    ignorées si une commande précédente échoue, sans que le client ait à gérer
+    cela explicitement avec des commandes <command>BEGIN</command> et
+    <command>COMMIT</command>. Les segments à valider indépendamment dans le
+    pipeline peuvent être séparées par des messages Sync.
+   </para>
+
+   <para>
+    Si le client n'a pas exécuté un <command>BEGIN</command> explicite, alors
+    chaque Sync implique un <command>COMMIT</command> implicite si les étapes
+    prédédentes ont réussi ou un <command>ROLLBACK</command> implicite si elles
+    ont échoué. Néanmoins, il existe quelques commandes DDL (comme
+    <command>CREATE DATABASE</command>) qui ne peuvent pas être exécutées dans
+    un bloc de transaction. Si une de ces commandes est exécutée dans un
+    pipeline, cela forcera une validation immédiate en cas de succès pour
+    préserver la cohérence de la base. Un Sync suivant immédiatement une des ces
+    commandes n'aura pas d'effet autre que de répondre avec ReadyForQuery.
+   </para>
+
+   <para>
+    Lors de l'utilisation de cette méthode, la fin du pipelin doit être
+    déterminée en comptant les messages ReadyForQuery et en attendant que cela
+    atteigne le nombre de Sync envoyés. Compter les réponses de fin de commande
+    n'est pas fiable car certaines commandes pourraient ne pas être exécutées et
+    donc ne pas produire de message de fin.
+   </para>
+  </sect2>
+
   <sect2>
    <title>Appel de fonction</title>
 

postgresql/ref/create_domain.xml

@@ -91,8 +91,8 @@
     <listitem>
      <para>
       Un collationement optionnel pour le domaine. Si aucun collationnement
-      n'est spécifié, le collationnement utilisé par défaut est celui du type
-      de données. Le type doit être collationnable si
+      n'est spécifié, le domaine a le même comportement de collation que le
+      type de données sous-jacent. Le type doit être collationnable si
       <literal>COLLATE</literal> est spécifié.
      </para>
     </listitem>

postgresql/ref/create_foreign_table.xml

@@ -30,11 +30,12 @@ CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="parameter">nom_table<
   { <replaceable class="parameter">nom_colonne</replaceable> [ WITH OPTIONS ] [ <replaceable class="parameter">contrainte_colonne</replaceable> [ ... ] ]
     | <replaceable>contrainte_table</replaceable> }
     [, ... ]
-) ] <replaceable class="parameter">spec_limites_partition</replaceable>
+) ]
+  FOR VALUES <replaceable class="parameter">spec_limites_partition</replaceable>
   SERVER <replaceable class="parameter">nom_serveur</replaceable>
 [ OPTIONS ( <replaceable class="parameter">option</replaceable> '<replaceable class="parameter">value</replaceable>' [, ... ] ) ]
 
-<phrase>where <replaceable class="parameter">contrainte_colonne</replaceable> is:</phrase>
+<phrase>où <replaceable class="parameter">contrainte_colonne</replaceable> vaut&nbsp;:</phrase>
 
 [ CONSTRAINT <replaceable class="parameter">nom_contrainte</replaceable> ]
 { NOT NULL |
@@ -46,6 +47,12 @@ CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="parameter">nom_table<
 
 [ CONSTRAINT <replaceable class="parameter">nom_contrainte</replaceable> ]
 CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ]
+
+<phrase>et <replaceable class="parameter">partition_bound_spec</replaceable> vaut&nbsp;:</phrase>
+
+IN ( { <replaceable class="parameter">litéral_numérique</replaceable> | <replaceable class="parameter">litéral_chaîne</replaceable> | TRUE | FALSE | NULL } [, ...] ) |
+FROM ( { <replaceable class="parameter">litéral_numérique</replaceable> | <replaceable class="parameter">litéral_chaîne</replaceable> | TRUE | FALSE | MINVALUE | MAXVALUE } [, ...] )
+  TO ( { <replaceable class="parameter">litéral_numérique</replaceable> | <replaceable class="parameter">litéral_chaîne</replaceable> | TRUE | FALSE | MINVALUE | MAXVALUE } [, ...] )
   </synopsis>
  </refsynopsisdiv>