Mise à jour en version 9.6.21

postgresql/arch-dev.xml

@@ -547,25 +547,32 @@
    <command>INSERT</command>, <command>UPDATE</command> et
    <command>DELETE</command>. Pour <command>SELECT</command>, le code de
    l'exécuteur de plus haut niveau a uniquement besoin d'envoyer chaque ligne
-   retournée par l'arbre plan de la requête vers le client. Pour
-   <command>INSERT</command>, chaque ligne renvoyée est insérée dans la table cible
-   indiquée par <command>INSERT</command>. Cela se fait dans un n&oelig;ud
-   spécial haut niveau du plan appelé <literal>ModifyTable</literal>. (Une
-   simple commande <command>INSERT ... VALUES</command> crée un arbre plan trivial
-   constitué d'un seul n&oelig;ud, <literal>Result</literal>, calculant une
-   seule ligne de résultat, et <literal>ModifyTable</literal> au-dessus pour
-   réaliser l'insertion.
-   Mais <command>INSERT ... SELECT</command> peut demander la pleine puissance du
-   mécanisme de l'exécuteur.) Pour <command>UPDATE</command>, le planificateur
-   s'arrange pour que chaque ligne calculée inclue toutes les valeurs mises à
-   jour des colonnes, plus le <firstterm>TID</firstterm> (tuple ID ou
-   l'identifiant de la ligne) de la ligne de la cible originale&nbsp;; cette
-   donnée est envoyée dans un n&oelig;ud <literal>ModifyTable</literal>, qui
-   utilise l'information pour créer une nouvelle ligne mise à jour et
-   marquer l'ancienne ligne comme supprimée. Pour <command>DELETE</command>,
-   la seule colonne renvoyée par le plan est le TID, et <literal>ModifyTable</literal>
-   node utilise simplement le TID pour visiter chaque ligne cible et la
-   marquer comme supprimée.
+   retournée par l'arbre plan de la requête vers le client. <command>INSERT
+   ... SELECT</command>, <command>UPDATE</command>, and
+   <command>DELETE</command> sont en réalité des <command>SELECT</command>
+   sous un nœud de plan haut niveau appelé <literal>ModifyTable</literal>.
+  </para>
+
+  <para>
+   <command>INSERT ... SELECT</command> remplit les lignes de
+   <literal>ModifyTable</literal> pour insertion. Pour
+   <command>UPDATE</command>, l'optimiseur s'arrange pour que chaque ligne
+   traitée inclut toutes les valeurs mises à jour des colonnes, plus le
+   <firstterm>TID</firstterm> (<foreignphrase>tuple ID</foreignphrase>, ou
+   identifiant de ligne) de la ligne cible originale&nbsp;; cette donnée est
+   envoyée au nœud <literal>ModifyTable</literal>, qui utilise l'information
+   pour créer un nouveau nœud mis à jour et pour marquer l'ancienne ligne
+   comme supprimée. Pour <command>DELETE</command>, la seule colonne qui est
+   réellement renvoyée par le plan est le TID, et le nœud
+   <literal>ModifyTable</literal> utilise simplement le TID pour visiter
+   chaque ligne cible et la marquer supprimée.
+  </para>
+
+  <para>
+   Une simple commande <command>INSERT ... VALUES</command> crée un arbre de
+   plan trivial consistant en un seul nœud <literal>Result</literal>, qui
+   calcule seulement une ligne résultat, en l'envoyant à
+   <literal>ModifyTable</literal> pour réaliser l'insertion.
   </para>
 
  </sect1>

postgresql/config.xml

@@ -1908,18 +1908,21 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
 
  <para>
   Il existe un processus serveur séparé appelé <firstterm>background
-   writer</firstterm> dont le but est d'écrire les tampons
-  <quote>sales</quote> (parce que nouveaux ou modifiés). Ce processus
-  écrit les tampons partagés pour que les processus serveur gérant les
-  requêtes des utilisateurs n'aient jamais ou peu fréquemment à attendre
-  qu'une écriture se termine. Néanmoins, ce processus d'écriture en
-  tâche de fond implique une augmentation globale de la charge des
-  entrées/sorties disque car, quand une page fréquemment modifiée
-  pourrait n'être écrite qu'une seule fois par CHECKPOINT, le processus
-  d'écriture en tâche de fond pourrait l'avoir écrit plusieurs fois si
-  cette page a été modifiée plusieurs fois dans le même intervalle. Les
-  paramètres discutés dans cette sous-section peuvent être utilisés
-  pour configurer finement son comportement pour les besoins locaux.
+  writer</firstterm> dont le but est d'écrire les tampons <quote>sales</quote>
+  (parce que nouveaux ou modifiés). Quand le nombre de tampons partagés
+  propres semble insuffisant, le <foreignphrase>background
+  writer</foreignphrase> écrit quelques tampons sales au système de fichiers
+  et les marque comme étant propres. Ceci réduit la probabilité que les
+  processus serveur gérant les requêtes des utilisateurs ne soient dans
+  l'incapacité de trouver des tampons propres et doivent écrire eux-mêmes des
+  tampons sales. Néanmoins, ce processus
+  d'écriture en tâche de fond implique une augmentation globale de la charge
+  des entrées/sorties disque car, quand une page fréquemment modifiée pourrait
+  n'être écrite qu'une seule fois par CHECKPOINT, le processus d'écriture en
+  tâche de fond pourrait l'avoir écrit plusieurs fois si cette page a été
+  modifiée plusieurs fois dans le même intervalle. Les paramètres discutés
+  dans cette sous-section peuvent être utilisés pour configurer finement son
+  comportement pour les besoins locaux.
  </para>
 
  <variablelist>

postgresql/datatype.xml

@@ -1165,6 +1165,15 @@ SELECT '52093.89'::money::numeric::float8;
     rationnelles.
    </para>
 
+   <para>
+    Les caractères pouvant être enregistrés dans chacun de ces types de
+    données sont déterminés par le jeu de caractères de la base de données,
+    qui a été sélectionné à la création de la base. Quelque soit le jeu de
+    caractères spécifique, le caractère de code zéro (quelque fois appelé NUL)
+    ne peut être enregistré. Pour plus d'informations, voir <xref
+    linkend="multibyte"/>.
+   </para>
+
    <para>
     L'espace nécessaire pour une chaîne de caractères courte (jusqu'à 126 octets)
     est de un octet, plus la taille de la chaîne qui inclut le remplissage avec
@@ -1210,10 +1219,6 @@ sa forme" -->
     On peut se référer à la <xref linkend="sql-syntax-strings"/> pour obtenir plus d'informations
     sur la syntaxe des libellés de chaînes, et le <xref linkend="functions"/>
     pour des informations complémentaires sur les opérateurs et les fonctions.
-    Le jeu de caractères de la base de données détermine celui
-    utilisé pour stocker les valeurs texte&nbsp;; pour plus
-    d'informations sur le support des jeux de caractères, se référer à
-    la <xref linkend="multibyte"/>.
    </para>
 
    <example>

postgresql/func.xml

@@ -6947,6 +6947,21 @@ les informations de base concernant les types de données date/heure de la <xref
 linkend="datatype-datetime"/>.
 </para>
 
+  <para>
+   De plus, les opérateurs de comparaison habituels affichés dans <xref
+   linkend="functions-comparison-table"/> sont disponibles pour les types
+   date/heure. Les dates et timestamps (avec ou sans fuseau horaire) sont tous
+   comparables, alors que les heures (avec et sans fuseau horaire) et les
+   intervalles peuvent seulement être comparés aux autres valeurs du même type
+   de données. Lors de la comparaison d'un timestamp sans fuseau horaire à un
+   timestamp avec fuseau horaire, la première valeur est supposée être donnée
+   dans le fuseau horaire indiqué par le paramètre de configuration <xref
+   linkend="guc-timezone"/>, et est transformée en UTC our comparaison avec la
+   deuxième valeur (qui est déjà en UTC). De façon similaire, une valeur date
+   est supposée représenter minuit dans la zone <varname>TimeZone</varname>
+   lors de la comparaison avec un timestamp.
+  </para>
+
 <para>
 Toutes les fonctions et opérateurs décrits ci-dessous qui acceptent une entrée de
 type <type>time</type> ou <type>timestamp</type> acceptent deux
@@ -7804,34 +7819,42 @@ SELECT EXTRACT(DAY FROM INTERVAL '40 days 1 minute');
       <term><literal>epoch</literal></term>
       <listitem>
        <para>
-        Pour les valeurs de type <type>timestamp with time zone</type>,
-        le nombre de secondes depuis le 1er janvier 1970 (exactement depuis le
-        1970-01-01 00:00:00 UTC). Ce nombre peut être négatif.
-        Pour les valeurs de type <type>date</type> et <type>timestamp</type>,
-        le nombre de secondes depuis le 1er janvier 1970 00h00, heure locale.
-        Pour les valeurs de type <type>interval</type>, il s'agit du nombre
-        total de secondes dans l'intervalle.
+        Pour les valeurs de type <type>timestamp with time zone</type>, le
+        nombre de secondes depuis le 1er janvier 1970 (exactement depuis le
+        1970-01-01 00:00:00 UTC). Ce nombre est négatif pour les timestamps
+        avant cette valeur. Pour les valeurs de type <type>date</type> et
+        <type>timestamp</type>, le nombre nominal de secondes depuis le 1er
+        janvier 1970 00h00, sans regard au fuseau horaire ou aux règles de
+        changement d'heure. Pour les valeurs de type <type>interval</type>, il
+        s'agit du nombre total de secondes dans l'intervalle.
        </para>
 
 <screen>SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40.12-08');
 <lineannotation>Résultat :
 </lineannotation><computeroutput>982384720.12</computeroutput>
 
+SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40.12');
+<lineannotation>Résultat : </lineannotation><computeroutput>982355920.12</computeroutput>
+
 SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
 <lineannotation>Résultat :
 </lineannotation><computeroutput>442800</computeroutput></screen>
 
        <para>
-        Vous pouvez convertir une valeur epoch en un timestamp avec
-        <function>to_timestamp</function>&nbsp;:
+        Vous pouvez convertir une valeur epoch vers un 
+        <type>timestamp with time zone</type>
+        avec <function>to_timestamp</function>&nbsp;:
        </para>
 
 <screen>SELECT to_timestamp(982384720.12);
 <lineannotation>Résultat : </lineannotation><computeroutput>2001-02-17 04:38:40.12+00</computeroutput>
    </screen>
    <para>
-    (La fonction <function>to_timestamp</function> encapsule la conversion
-    ci-dessus.)
+    Attention que l'application de <function>to_timestamp</function> à un
+    epoch extrait d'une valeur <type>date</type> ou <type>timestamp</type>
+    pourrait produire un résultat trompeur&nbsp;: le résultat supposera en
+    fait que la valeur originale a été donnée en UTC, ce qui pourrait ne
+    pas être le cas.
    </para>
   </listitem>
  </varlistentry>
@@ -11209,11 +11232,13 @@ transformation-table2
 
   <note>
    <para>
-    L'opérateur <literal>||</literal> concatène les éléments
-    situés au premier niveau de chacun de ses opérandes. Il n'opère pas
-    récursivement. Par exemple, si les deux opérandes sont des objets
-    avec une clef commune, la valeur du champ dans le résultat sera
-    uniquement celle de l'opérande de droite.
+    L'opérateur <literal>||</literal> concatène deux objets JSON en générant
+    un objet contenant l'union de leurs clés, en prenant la valeur du deuxième
+    objet quand les clés sont dupliquées. Tous les autres cas produisent un
+    tableau JSON&nbsp;: tout d'acord, tout entrée qui n'est pas un tableau est
+    convertie en un tableau à un seul élément, puis les deux tableaux sont
+    concaténés. Il ne travaille pas récursivement. Seul le tableau ou la
+    structure objet de haut niveau est assemblé.
    </para>
   </note>
 

postgresql/installation.xml

@@ -2699,6 +2699,18 @@ make MAX_CONNECTIONS=5 check
     <secondary>installation sur</secondary>
    </indexterm>
 
+   <para>
+    Pour construire <productname>PostgreSQL</productname> à partir des sources
+    sur <productname>macOS</productname>, vous aurez besoin d'installer les
+    outils développeur en ligne de commande d'Apple, ce qui se fait en
+    exécutant
+<programlisting>
+xcode-select --install
+</programlisting>
+    (notez que cela affichera une fenêtre graphique pour confirmation). Vous
+    pouvez aussi installer Xcode.
+   </para>
+
    <para>
     Sur les versions récentes de <productname>macOS</productname>, il est
     nécessaire d'embarquer le chemin <quote>sysroot</quote> dans les options
@@ -2717,7 +2729,7 @@ make PG_SYSROOT=<replaceable>/desired/path</replaceable> all
     </programlisting>
     Pour trouver le chemin approprié sur votre machine, lancez
     <programlisting>
-xcodebuild -version -sdk macosx Path
+xcrun --show-sdk-path
     </programlisting>
     Notez que compiler une extension en utilisant une version sysroot
     différente de celle utilisée pour compiler le serveur n'est pas
@@ -2732,6 +2744,21 @@ xcodebuild -version -sdk macosx Path
     <programlisting>
 ./configure ... PG_SYSROOT=<replaceable>/desired/path</replaceable>
     </programlisting>
+    Ceci sera principalement utile pour faire de la cross-compilation pour
+    d'autres versions de macOS. Il n'y a pas de garantie que les exécutables
+    qui vont en résulter fonctionneront sur l'hôte actuel.
+   </para>
+
+   <para>
+    Pour supprimer les options <option>-isysroot</option>, utilisez
+<programlisting>
+./configure ... PG_SYSROOT=none
+</programlisting>
+
+    (tout nom de chemin non existant fonctionnera). Ceci pourrait être utile
+    si vous souhaitez compiler avec un compilateur autre que celui d'Apple,
+    mais attention au fait que ce cas n'est ni testé ni supporté par les
+    développeurs PostgreSQL.
    </para>
 
    <para>

postgresql/legal.xml

@@ -1,16 +1,16 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<date>2020</date>
+<date>2021</date>
 
 <copyright>
- <year>1996-2020</year>
+ <year>1996-2021</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
 <legalnotice id="legalnotice">
  <title>Legal Notice</title>
 
  <para>
-  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2020
+  <productname>PostgreSQL</productname> is Copyright &copy; 1996-2021
   by the PostgreSQL Global Development Group.
  </para>