Mise à jour en version 9.6.22

postgresql/acronyms.xml

@@ -689,6 +689,16 @@
     </listitem>
    </varlistentry>
 
+   <varlistentry>
+    <term><acronym>TLS</acronym></term>
+    <listitem>
+     <para>
+      <ulink url="https://en.wikipedia.org/wiki/Transport_Layer_Security">
+      Transport Layer Security</ulink>
+     </para>
+    </listitem>
+   </varlistentry>
+
    <varlistentry>
     <term><acronym>TOAST</acronym></term>
     <listitem>

postgresql/backup.xml

@@ -952,8 +952,10 @@ SELECT * FROM pg_stop_backup(false);
       valeurs. Le second de ces champs devrait être écrit dans un fichier nommé
       <filename>backup_label</filename> dans le répertoire racine de la sauvegarde.
       Le troisième champ devrait être écrit dans un fichier nommé
-      <filename>tablespace_map</filename> sauf si le champ est vide. Ces fichiers
-      sont vitaux pour le fonctionnement de la sauvegarde et doivent être écrits sans modification.
+      <filename>tablespace_map</filename> sauf si le champ est vide. Ces
+      fichiers sont vitaux pour le fonctionnement de la sauvegarde et doivent
+      être écrits octet par octet sans modification, ce qui nécessite d'ouvrir
+      le fichier en mode binaire.
      </para>
     </listitem>
     <listitem>

postgresql/config.xml

@@ -2592,7 +2592,8 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
     <para>
      Ces options ne sont pas toutes disponibles sur toutes les plateformes.
      La valeur par défaut est la première méthode de la liste ci-dessus
-     supportée par la plateforme.
+     supportée par la plateforme, sauf que <literal>fdatasync</literal> est la
+     valeur par défaut sur Linux et FreeBSD.
      Les options <literal>open_</literal>* utilisent aussi
      <literal>O_DIRECT</literal> s'il est disponible.
      L'outil <filename>src/tools/fsync</filename> disponible dans le code

postgresql/datetime.xml

@@ -822,9 +822,6 @@
   <indexterm zone="datetime-units-history">
    <primary>calendrier Grégorien</primary>
   </indexterm>
-  <indexterm zone="datetime-units-history">
-   <primary>date Julien</primary>
-  </indexterm>
 
   <para>
    Le standard SQL précise que à l'intérieur de la définition d'un
@@ -925,14 +922,27 @@ di lu ma me je ve sa
    civils. Le calendrier chinois est utilisé pour déterminer les festivals.
   </para>
 
+  </sect1>
+
+  <sect1 id="datetime-julian-dates">
+  <title>Dates Julien</title>
+
+  <indexterm zone="datetime-julian-dates">
+   <primary>Date Julien</primary>
+  </indexterm>
+
   <para>
-   Le système de <firstterm>dates Julien</firstterm> est un autre
-   type de calendrier, non relatif au calendrier Julien, malgré la
-   similarité du nom.
+   Le système de <firstterm>dates Julien</firstterm> est une méthode pour
+   numéroter les jours. Il n'a pas de relation avec le calendrier Julien,
+   malgré la similarité du nom.
    Le système de date Julien a été inventé par le précepteur
    français Joseph Justus Scaliger (1540-1609) et tient probablement son nom
    du père de Scaliger, le précepteur italien Julius Caesar Scaliger
-   (1484-1558). Dans le système de date Julien, chaque jour est un nombre
+   (1484-1558).
+  </para>
+
+  <para>
+   Dans le système de date Julien, chaque jour est un nombre
    séquentiel, commençant à partir de JD 0, appelé quelque fois
    <emphasis>la</emphasis> date Julien. JD 0 correspond au 1er janvier
    4713 avant JC dans le calendrier Julien, ou au 24 novembre 4714 avant JC
@@ -948,7 +958,31 @@ di lu ma me je ve sa
    l'affichage des dates en notation de date Julien (et les utilise aussi pour
    quelques calculs internes de date et heure), il n'utilise pas le coup
    des dates de midi à midi. <productname>PostgreSQL</productname> traite une
-   date Julien comme allant de minuit à minuit.
+   date Julien comme allant de minuit heure locale à minuit heure locale,
+   de la même façon que pour une date normale.
+  </para>
+
+  <para>
+   Néanmoins, cette définition fournit une méthode pour obtenir la définition
+   astronomique quand vous en avez besoin&nbsp;: faites le calcul dans le
+   fuseau horaire <literal>UTC+12</literal>. Par exemple,
+<programlisting>
+=&gt; SELECT extract(julian from '2021-06-23 7:00:00-04'::timestamptz at time zone 'UTC+12');
+     date_part
+--------------------
+ 2459388.9583333335
+(1 row)
+=&gt; SELECT extract(julian from '2021-06-23 8:00:00-04'::timestamptz at time zone 'UTC+12');
+ date_part
+-----------
+   2459389
+(1 row)
+=&gt; SELECT extract(julian from date '2021-06-23');
+ date_part
+-----------
+   2459389
+(1 row)
+</programlisting>
   </para>
  </sect1>
 </appendix>

postgresql/ddl.xml

@@ -758,6 +758,11 @@ DROP TABLE produits;</programlisting>
 	table de référence est utilisée comme colonne de référence.
        </para>
 
+       <para>
+        Une contrainte de clé étrangère peut être nommée de la façon
+        habituelle.
+       </para>
+
        <para>
 	Une clé étrangère peut aussi contraindre et référencer un groupe de colonnes.
 	Comme cela a déjà été évoqué, il faut alors l'écrire sous forme d'une contrainte de table.
@@ -772,8 +777,29 @@ DROP TABLE produits;</programlisting>
 	au nombre et au type des colonnes référencées.
        </para>
 
+   <indexterm>
+    <primary>clé étrangère</primary>
+    <secondary>auto-référencé</secondary>
+   </indexterm>
+
        <para>
-	Une contrainte de clé étrangère peut être nommée de la façon habituelle.
+        Parfois, il est utile que l'<quote>autre table</quote> d'une clé
+        étrangère soit la même table&nbsp;; elle est alors appelée une clé
+        étrangère <firstterm>auto-référencée</firstterm>. Par exemple, si vous
+        voulez que les lignes d'une table représentent les nœuds d'une
+        structure en arbre, vous pouvez écrire
+<programlisting>
+CREATE TABLE tree (
+    node_id integer PRIMARY KEY,
+    parent_id integer REFERENCES tree,
+    name text,
+    ...
+);
+</programlisting>
+        Un nœud racine aura la colonne <structfield>parent_id</structfield> à
+        NULL, et les enregistrements non NULL de
+        <structfield>parent_id</structfield> seront contraints de référencer
+        des enregistrements valides de la table.
        </para>
 
        <para>
@@ -1990,7 +2016,8 @@ SELECT * FROM information WHERE groupe_id = 2 FOR UPDATE;
         performance, tout spécialement si des mises à jour de cette table sont
         fréquentes. Une autre solution envisageable, si les mises à jour de
         la table référencée ne sont pas fréquentes, est de prendre un
-        verrou exclusif sur la table référencée lors des mises à jour,
+        verrou de type <literal>ACCESS EXCLUSIVE</literal> sur la table
+        référencée lors des mises à jour,
         de telle manière qu'aucune autre transaction concurrente ne pourrait
         consulter d'anciennes valeurs. Ou une transaction pourrait attendre que
         toutes les transactions se terminent après avoir validées une mise

postgresql/func.xml

@@ -6213,8 +6213,8 @@ disponibles pour formater les valeurs de types date et heure.
   </row>
   <row>
    <entry><literal>J</literal></entry>
-   <entry>nombre de jours dans le calendrier Julien (nombre de jours depuis le 24
-    novembre -4714 à minuit)</entry>
+   <entry>Date Julien (nombre de jours depuis le 24 novembre -4714 à minuit
+    heure locale&nbsp;; voir <xref linkend="datetime-julian-dates"/>)</entry>
   </row>
   <row>
    <entry><literal>Q</literal></entry>
@@ -7920,6 +7920,25 @@ SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-02');
   </listitem>
  </varlistentry>
 
+     <varlistentry>
+      <term><literal>julian</literal></term>
+      <listitem>
+       <para>
+        La <firstterm>Date Julien</firstterm> correspondant à la date
+        ou à l'horodatage (non applicable aux intervalles). Les horodatages
+        qui ne sont pas à minuit heure locale résultent en une valeur fractionnelle. Voir
+        <xref linkend="datetime-julian-dates"/> pour plus d'informations.
+       </para>
+
+<screen>
+SELECT EXTRACT(JULIAN FROM DATE '2006-01-01');
+<lineannotation>Result: </lineannotation><computeroutput>2453737</computeroutput>
+SELECT EXTRACT(JULIAN FROM TIMESTAMP '2006-01-01 12:00');
+<lineannotation>Result: </lineannotation><computeroutput>2453737.5</computeroutput>
+</screen>
+      </listitem>
+     </varlistentry>
+
  <varlistentry>
   <term><literal>microseconds</literal></term>
   <listitem>

postgresql/hstore.xml

@@ -636,15 +636,16 @@ UPDATE nom_table SET col_hstore = col_hstore || '';
    <programlisting>
 ALTER TABLE nom_table ALTER col_hstore TYPE col_hstore USING hstorecol || '';
    </programlisting>
-   La méthode <command>ALTER TABLE</command> requiert un verrou exclusif sur
+   La méthode <command>ALTER TABLE</command> requiert un verrou de type
+   <literal>ACCESS EXCLUSIVE</literal> sur
    la table mais n'a pas pour résultat une fragmentation de la table avec
    d'anciennes versions des lignes.
   </para>
 
  </sect2>
 
  <sect2>
-  <title>Transforms</title>
+  <title>Transformations</title>
 
   <para>
    Des extensions supplémentaires sont disponibles pour implémenter des

postgresql/indexam.xml

@@ -844,9 +844,10 @@ amrestrpos (IndexScanDesc scan);
    <literal>RowExclusiveLock</literal> lors de sa mise à jour (ce qui inclut le
    <command>VACUUM</command> simple). Comme ces types de
    verrous ne sont pas conflictuels, la méthode d'accès est responsable de la
-   finesse du verrouillage dont elle a besoin. Un verrou exclusif sur
-   l'intégralité de l'index entier n'est posé qu'à la création de l'index, sa destruction
-   ou lors d'un <literal>REINDEX</literal>.
+   finesse du verrouillage dont elle a besoin. Un verrou de type
+   <literal>ACCESS EXCLUSIVE</literal> sur l'intégralité de l'index entier
+   n'est posé qu'à la création de l'index, sa destruction ou lors d'un
+   <literal>REINDEX</literal>.
   </para>
 
   <para>

postgresql/libpq.xml

@@ -4555,15 +4555,37 @@ char *PQresultVerboseErrorMessage(const PGresult *res,
 
   <para>
    <function>PQfn</function> renvoie toujours un pointeur
-   <structname>PGresult</structname> valide. L'état du résultat devrait être
+   <structname>PGresult</structname> valide, avec un statut
+   <literal>PGRES_COMMAND_OK</literal> en cas de succès et
+   <literal>PGRES_FATAL_ERROR</literal> si un problème a été rencontré. L'état
+   du résultat devrait être
    vérifié avant que le résultat ne soit utilisé. Le demandeur est responsable de
    la libération de la structure <structname>PGresult</structname>  avec
    <function>PQclear</function> lorsque celle-ci n'est plus nécessaire.
   </para>
 
   <para>
-   Notez qu'il n'est pas possible de gérer les arguments nuls, les résultats nuls
-   et les résultats d'ensembles nuls en utilisant cette interface.
+   Pour passer un argument NULL à la fonction, configurez le champ
+   <parameter>len</parameter> de cette structure à
+   <literal>-1</literal>&nbsp;; les champs <parameter>isint</parameter>
+   et <parameter>u</parameter> sont alors hors sujet.
+   (Cependant, ceci ne fonctionne que pour les connexions en protocole
+   3.0 et ultérieures.)
+  </para>
+
+  <para>
+   Si la fonction renvoie NULL, <parameter>*result_len</parameter> est
+   configuré à <literal>-1</literal>, et <parameter>*result_buf</parameter>
+   n'est pas modifié. (Ceci fonctionne seulement pour les connexions en
+   protocole 3.0 et ultérieures&nbsp;; avec le protocole 2.0, ni
+   <parameter>*result_len</parameter> ni <parameter>*result_buf</parameter> ne
+   sont modifiés.)
+  </para>
+
+  <para>
+   Notez qu'il n'est pas possible de gérer des ensembles de résultats en
+   utilisant cette interface. De plus, la fonction doit être une fonction
+   standard, par une fonction d'agrégat ou une fonction de fenêtrage.
   </para>
 
  </sect1>

postgresql/maintenance.xml

@@ -131,7 +131,8 @@
     <command>DELETE</command> continuent de fonctionner de façon normale,
     mais la définition d'une table ne peut être modifiée avec des
     commandes telles que <command>ALTER TABLE</command> pendant le <command>VACUUM</command>.
-    <command>VACUUM FULL</command> nécessite un verrou exclusif sur la table sur
+    <command>VACUUM FULL</command> nécessite un verrou de type <literal>ACCESS
+    EXCLUSIVE</literal> sur la table sur
     laquelle il travaille, et ne peut donc pas être exécuté en parallèle avec une
     autre activité sur la table. En règle générale,
     par conséquent, les administrateurs doivent s'efforcer d'utiliser la commande
@@ -240,8 +241,9 @@
      gaspillé, <command>VACUUM FULL</command> peut être utilisé,
      <xref linkend="sql-cluster"/> ou une des variantes de <xref
      linkend="sql-altertable"/>.
-     Ces commandes écrivent une nouvelle copie de la table et lui adjoignent de nouveaux
-     index. Toutes ces options nécessitent un verrou exclusif.
+     Ces commandes écrivent une nouvelle copie de la table et lui adjoignent
+     de nouveaux index. Toutes ces options nécessitent un verrou de type
+     <literal>ACCESS EXCLUSIVE</literal>.
      Elles utilisent aussi temporairement un espace disque supplémentaire,
      approximativement égal à la taille de la table, car les anciennes copies de
      la table et des index ne peuvent pas être supprimées avant la fin de

postgresql/mvcc.xml

@@ -868,7 +868,8 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
    façon incompatible lorsque la commande s'exécute (par exemple,
    <command>TRUNCATE</command> ne peut pas être exécuté de façon sûre en
    même temps que d'autres opérations sur la même table, donc il obtient un
-   verrou exclusif sur la table pour s'assurer d'une bonne exécution).
+   verrou de type <literal>ACCESS EXCLUSIVE</literal> sur la table pour
+   s'assurer d'une bonne exécution).
   </para>
 
   <para>

postgresql/pgrowlocks.xml

@@ -93,8 +93,8 @@ pgrowlocks(text) returns setof record
   <orderedlist>
    <listitem>
     <para>
-     Si la table entière est verrouillée exclusivement par quelqu'un d'autre,
-     <function>pgrowlocks</function> sera bloqué.
+     Si un verrou de type <literal>ACCESS EXCLUSIVE</literal> est posée sur la
+     table, <function>pgrowlocks</function> sera bloqué.
     </para>
    </listitem>
    <listitem>

postgresql/ref/alter_table.xml

@@ -368,6 +368,10 @@ ALTER TABLE ALL IN TABLESPACE <replaceable class="PARAMETER">nom</replaceable> [
        endterm="sql-altertable-notes-title"/> ci-dessous pour une explication
        de l'utilité de cette commande.)
       </para>
+      <para>
+       Cette commande récupère un verrou de type <literal>SHARE UPDATE
+       EXCLUSIVE</literal>.
+      </para>
      </listitem>
     </varlistentry>
 

postgresql/ref/drop_index.xml

@@ -40,7 +40,8 @@ DROP INDEX [ CONCURRENTLY ] [ IF EXISTS ] <replaceable class="PARAMETER">nom</re
      <para>
       Supprime l'index sans verrouiller les lectures et les modifications
       (insertions, modifications, suppressions) sur la table de l'index.
-      Un <command>DROP INDEX</command> standard acquiert un verrou exclusif
+      Un <command>DROP INDEX</command> standard acquiert un verrou de type
+      <literal>ACCESS EXCLUSIVE</literal>
       sur la table, bloquant tous les autres accès jusqu'à ce que la suppression
       de l'index soit terminée. Avec cette option, la commande attends que toute
       transaction en conflit soit terminée.

postgresql/ref/pg_basebackup.xml

@@ -169,6 +169,7 @@
            répertoire principal des données sera placé dans le répertoire
            cible mais les autres tablespaces seront placés dans le même
            chemin absolu que celui d'origine.
+           (Voir <option>--tablespace-mapping</option> pour changer cela.)
           </para>
           <para>
            C'est le format par défaut.
@@ -284,7 +285,13 @@
        Si un tablespace est transféré de cette façon, les liens symboliques à
        l'intérieur du répertoire de données principal sont mis à jour pour
        pointer vers le nouvel emplacement. Du coup, le nouveau répertoire de
-       données est prêt à être utilisé sur la nouvelle instance.
+       données est prêt à être utilisé sur la nouvelle instance avec tous les
+       tablespaces dans les emplacements mis à jour.
+      </para>
+
+      <para>
+       Actuellement, cette option ne fonctionne qu'avec le format de sortie
+       plain. Elle est ignorée sur le format tar est sélectionné.
       </para>
      </listitem>
     </varlistentry>

postgresql/ref/reindex.xml

@@ -212,10 +212,12 @@
    création de l'index. Dans les faits, le contenu de l'index est complètement
    recréé. Néanmoins, les considérations de verrouillage sont assez
    différentes. <command>REINDEX</command> verrouille les écritures mais pas les
-   lectures de la table mère de l'index. Il positionne également un verrou exclusif sur
-   l'index en cours de traitement, ce qui bloque les lectures qui tentent
-   de l'utiliser. Au contraire, <command>DROP INDEX</command> crée temporairement
-   un verrou exclusif sur la table parent, bloquant ainsi écritures et lectures.
+   lectures de la table mère de l'index. Il positionne également un verrou de
+   type <literal>ACCESS EXCLUSIVE</literal> sur l'index en cours de
+   traitement, ce qui bloque les lectures qui tentent de l'utiliser. Au
+   contraire, <command>DROP INDEX</command> prends temporairement un verrou de
+   type <literal>ACCESS EXCLUSIVE</literal> sur la table parent, bloquant
+   ainsi écritures et lectures.
    Le <command>CREATE INDEX</command> qui suit verrouille les écritures mais pas les
    lectures&nbsp;; comme l'index n'existe pas, aucune lecture ne peut être
    tentée, signifiant qu'il n'y a aucun blocage et que les lectures sont