Mise à jour en version 12.12

postgresql/brin.xml

@@ -15,7 +15,11 @@
    <acronym>BRIN</acronym> est concu pour gérer de grosses tables
    dont certaines ont des colonnes ayant une corrélation naturelle avec
    leur stockage physique.
+  </para>
 
+  <para>
+   <acronym>BRIN</acronym> fonctionne en terme d'<firstterm>intervalle de blocs</firstterm>
+   (ou <quote>intervalle de pages</quote>).
    Un <firstterm>intervalle de bloc</firstterm>
    est un groupe de pages physiquement adjacentes dans la table&nbsp;;
    Pour chaque gamme de bloc, un résumé des informations est stocké par
@@ -83,38 +87,62 @@
     dans des résumés, cela va entrainer la mise à jour du résumé, avec les
     informations sur les nouvelles lignes insérées.
 
-    Lorsqu'une nouvelle page est créée et qu'elle ne correspond à aucun
-    des derniers intervalles résumés, l'intervalle ne crée pas automatiquement
-    un résumé. Ces lignes restent non catégorisées jusqu'à ce qu'un processus
-    soit lancé pour le faire, créant alors les résumés initiaux.
-
-    Ce processus peut être appelé manuellement en exécutant la fonction
-    <function>brin_summarize_range(regclass, bigint)</function> ou la fonction
-    <function>brin_summarize_new_values(regclass)</function>&nbsp;;
-    automatiquement lorsque <command>VACUUM</command> va inspecter la
-    table&nbsp;;
-    ou par un résumé automatique effectué par autovacuum, au fur et à mesure que
-    des insertions sont effectuées.  (Ce dernier déclencheur est désactivé par
-    défaut, et peut être activé avec le paramètre
-    <literal>autosummarize</literal>.)  Inversement, le résumé d'un intervalle peut être
-    supprimé en utilisant la fonction <function>brin_desummarize_range(regclass,
-     bigint)</function>, ce qui peut être utile quand la ligne de l'index n'est
-    plue une bonne représentation du fait des changements des valeurs
-    existantes.
+    Lorsqu'une nouvelle page est créée et qu'elle ne correspond à aucun des
+    derniers intervalles résumés, l'intervalle auquel appartient la nouvelle
+    page n'acquiert pas automatiquement un résumé&nbsp;; ces lignes restent sans
+    résumé jusqu'à ce qu'une exécution de résumé soit demandée plus tard, créant
+    ainsi le résumé initial pour cet intervalle.
+   </para>
+
+   <para>
+    Il existe plusieurs façons de déclencher le résumé initial d'un intervalle
+    de blocs. Si la table est traitée par VACUUM, soit manuellement soit par
+    l'<link linkend="autovacuum">autovacuum</link>, tous les intervalles de
+    blocs existants non résumés sont résumés. De plus, si le paramètre <xref
+    linkend="index-reloption-autosummarize"/> de l'index est activé, ce qui
+    n'est pas le cas par défaut, à chaque fois que l'autovacuum est exécuté dans
+    cette base, le résumé surviendra pour tous les intervalles de blocs non
+    résumés qui ont été remplis, que la table elle-même soit traitée par
+    l'autovacuum ou pas&nbsp;; voir ci-dessous.
    </para>
 
    <para>
-    Quand le résumé automatique est activé, chaque fois qu'un intervalle de
-    page est rempli, une requête est envoyée à autovacuum pour qu'il exécute un
-    résumé ciblé pour cet intervalle, opération à exécuter à la fin du travail
-    du prochain worker sur la même base de données. Si la queue des demandes
-    est remplie, la demande n'est pas enregistré et un message est enregistré
-    dans les traces du serveur&nbsp;:
+    Dernièrement, les fonctions suivantes peuvent être utilisées&nbsp;:
+    <simplelist>
+     <member>
+      <function>brin_summarize_new_values(regclass)</function>
+      qui résume tous les blocs sans résumé&nbsp;;
+     </member>
+     <member>
+      <function>brin_summarize_range(regclass, bigint)</function>
+      qui résume seulement l'intervalle contenant le bloc donné
+      s'il n'est pas résumé.
+     </member>
+    </simplelist>
+   </para>
+
+   <para>
+    Quand le résumé automatique est activé, une requête est envoyée à
+    l'<literal>autovacuum</literal> pour exécuter un résumé cible pour un
+    intervalle de bloc quand une insertion est détecté pour le premier élément
+    du premier bloc du prochain intervalle de bloc, opération à réaliser la
+    prochaine fois qu'un autovacuum worker finit son exécution dans la même
+    base. Si la queue des demandes est remplie, la demande n'est pas
+    enregistrée et un message est enregistré dans les traces du serveur&nbsp;:
     <screen>
 LOG:  request for BRIN range summarization for index "brin_wi_idx" page 128 was not recorded
     </screen>
-    Quand cela arrive, l'intervalle sera résumé avec la méthode habituelle lors
-    du prochain VACUUM standard de la table.
+    Quand cela arrive, l'intervalle restera non résumé jusqu'à la prochaine
+    exécution d'un vacuum standard sur la table ou jusqu'à ce qu'une des
+    fonctions mentionnées ci-dessus soit appelée.
+   </para>
+
+   <para>
+    Inversement, un intervalle peut se voir supprimer son résumé avec la
+    fonction <function>brin_desummarize_range(regclass, bigint)</function>, qui
+    est utile quand l'enregistrement de l'index n'est plus une très bonne
+    représentation car les valeurs existantes ont changées. Voir <xref
+    linkend="functions-admin-index"/> pour les détails.
    </para>
   </sect2>
  </sect1>

postgresql/client-auth.xml

@@ -415,7 +415,10 @@ hostnogssenc  <replaceable>database</replaceable>  <replaceable>user</replaceabl
       <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

@@ -7207,8 +7207,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>
@@ -9922,6 +9924,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

@@ -3869,11 +3869,12 @@ opposition de deux choses -->
        <para>
         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.
+        la première forme (avec les :) comme utilisé avec la notation à bits
+        retournés, MSB en premier,
+        ce qui donne l'équivalence 08-00-2b-01-02-03 = 01: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&nbsp;; tous les formats
         acceptés utilisent l'ordre canonique LSB.
        </para>
 

postgresql/ecpg.xml

@@ -1817,6 +1817,8 @@ EXEC SQL SELECT b INTO :val :val_ind FROM test1;
     </programlisting>
     La variable indicateur <varname>val_ind</varname> sera zéro si
     la valeur n'était pas nulle, et sera négative si la valeur était nulle.
+    (Voir <xref linkend="ecpg-oracle-compat"/> pour activer un comportement
+    spécifique à Oracle.)
    </para>
 
    <para>
@@ -9680,6 +9682,44 @@ risnull(CINTTYPE, (char *) &i);
  </sect2>
 </sect1>
 
+<sect1 id="ecpg-oracle-compat">
+ <title>Mode de compatibilité <productname>Oracle</productname></title>
+
+ <para>
+  <command>ecpg</command> peut être exécuté dans un <firstterm>mode de
+  compatibilité Oracle</firstterm>. Si ce mode est actif, il essaie de se
+  comporter comme si c'était du <productname>Pro*C</productname> Oracle.
+ </para>
+
+ <para>
+  En fait, ce mode change le comportement d'<command>ecpg</command> de trois
+  façons&nbsp;:
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Remplit les tableaux de caractères recevant des types chaîne de caractères
+     avec des espaces à la fin pour obtenir la longueur indiquée
+    </para>
+   </listitem>
+
+   <listitem>
+    <para>
+     Un octet zéro termine ces tableaux de caractères, et configure la variable
+     indicateur si la troncature survient
+    </para>
+   </listitem>
+
+   <listitem>
+    <para>
+     Configure l'indicateur null à <literal>-1</literal> quand les tableaux de
+     caractères reçoivent des types de chaînes de caractères vides
+    </para>
+   </listitem>
+  </itemizedlist>
+ </para>
+</sect1>
+
 <sect1 id="ecpg-develop">
  <title>Fonctionnement Interne</title>
 

postgresql/extend.xml

@@ -1127,17 +1127,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/func.xml

@@ -1172,6 +1172,9 @@ champs, adressable en tant qu'entité.) -->
  <function>setseed()</function> est appelée, les résultats des appels suivant
  à <function>random()</function> dans la même session sont répétables en
  réexécutant <function>setseed()</function> avec le même argument.
+ Sans un appel précédent à <function>setseed()</function> dans la même session,
+ le premier appel à <function>random()</function> obtient une graine d'une
+ source dépendante de la plateforme de bits aléatoires.
 </para>
 
 <para>

postgresql/install-windows.xml

@@ -552,15 +552,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/json.xml

@@ -424,18 +424,21 @@ SELECT doc->'site_name' FROM websites
   </para>
   <para>
    La classe d'opérateur GIN par défaut pour <type>jsonb</type> supporte les
-   requêtes avec des opérateurs de haut niveau clé-existe <literal>?</literal>, <literal>?&amp;</literal>
-   et des opérateurs <literal>?|</literal> et l'opérateur path/valeur-existe
-   <literal>@&gt;</literal>.
+   requêtes avec des opérateurs clé-existe <literal>?</literal>,
+   <literal>?|</literal> et <literal>?&amp;</literal>, l'opérateur de contenant
+   <literal>@&gt;</literal>, et les opérateurs de correspondance
+   <type>jsonpath</type> <literal>@?</literal> et <literal>@@</literal>.
    (Pour des détails sur la sémantique que ces opérateurs implémentent,
    voir <xref linkend="functions-jsonb-op-table"/>.)
    Un exemple de création d'index avec cette classe d'opérateurs est&nbsp;:
    <programlisting>
 CREATE INDEX idxgin ON api USING GIN (jdoc);
    </programlisting>
-   La classe d'opérateurs GIN qui n'est pas par défaut <literal>jsonb_path_ops
-   </literal> supporte l'indexation de l'opérateur <literal>@&gt;</literal>
-   seulement.  Un exemple de création d'index avec cette classe d'opérateurs est&nbsp;:
+   La classe d'opérateurs GIN qui n'est pas par défaut
+   <literal>jsonb_path_ops</literal> ne supporte pas les opérateurs clé-existe,
+   mais supporte <literal>@&gt;</literal>, <literal>@?</literal> et
+   <literal>@@</literal>.
+   Un exemple de création d'index avec cette classe d'opérateurs est&nbsp;:
    <programlisting>
 CREATE INDEX idxginp ON api USING GIN (jdoc jsonb_path_ops);
    </programlisting>
@@ -495,23 +498,6 @@ CREATE INDEX idxgintags ON api USING GIN ((jdoc -&gt; 'tags'));
    (Plus d'informations sur les index sur expression peuvent être
    trouvées dans <xref linkend="indexes-expressional"/>.)
   </para>
-  <para>
-   Les index GIN supportent aussi les opérateurs <literal>@@</literal>
-   et <literal>@?</literal> qui réalisent la correspondance avec le
-   <literal>jsonpath</literal>.
-   <programlisting>
-SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
-   </programlisting>
-   <programlisting>
-SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @? '$.tags[*] ? (@ == "qui")';
-   </programlisting>
-   L'index GIN extrait les informations de la forme suivante du
-   <literal>jsonpath</literal>&nbsp;: <replaceable>chaîne d'accès</replaceable> = <replaceable>const</replaceable>.
-   La chaîne d'accès peut être <literal>.key</literal>,
-   <literal>[*]</literal> et <literal>[<replaceable>index</replaceable>]</literal>.
-   <literal>jsonb_ops</literal> supporte aussi les accesseurs <literal>.*</literal>
-   et <literal>.**</literal>.
-  </para>
   <para>
    Une autre approche pour le requêtage et l'exploitation de l'inclusion, par exemple&nbsp;:
    <programlisting>
@@ -529,10 +515,33 @@ SELECT jdoc-&gt;'guid', jdoc-&gt;'name' FROM api WHERE jdoc @&gt; '{"tags": ["qu
    et plus rapides pour la recherche qu'un simple index.
   </para>
 
+  <para>
+   Les index GIN supportent aussi les opérateurs <literal>@?</literal>
+   et <literal>@@</literal>, qui réalisent la correspondance
+   <type>jsonpath</type>. Voici des exemples&nbsp;:
+<programlisting>
+SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @? '$.tags[*] ? (@ == "qui")';
+</programlisting>
+<programlisting>
+SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
+</programlisting>
+   Pour ces opérateurs, un index GIN extrait les clauses de la forme
+   <literal><replaceable>chaine_accesseurs</replaceable> =
+   <replaceable>constante</replaceable></literal> en dehors du motif
+   <type>jsonpath</type>, et réalise la recherche avec l'index en se basant sur
+   les clés et les valeurs mentionnées dans ces clauses. La chaîne des
+   accesseurs peut inclure <literal>.<replaceable>key</replaceable></literal>,
+   <literal>[*]</literal>, et les accesseurs
+   <literal>[<replaceable>index</replaceable>]</literal>.  La classe d'opérateur
+   <literal>jsonb_ops</literal> accepte aussi les accesseurs
+   <literal>.*</literal> et <literal>.**</literal>, mais la classe d'opérateur
+   <literal>jsonb_path_ops</literal> ne l'accepte pas.
+  </para>
+
   <para>
    Bien que la classe d'opérateur <literal>jsonb_path_ops</literal> ne supporte
-   que les requêtes avec les opérateurs <literal>@&gt;</literal>, <literal>@@</literal>
-   et <literal>@?</literal>, elle a des
+   que les requêtes avec les opérateurs <literal>@&gt;</literal>, <literal>@?</literal>
+   et <literal>@@</literal>, elle a des
    avantages de performances notables par rapport à la classe d'opérateur par
    défaut <literal>jsonb_ops</literal>.  Un index <literal>jsonb_path_ops</literal>
    est généralement bien plus petit qu'un index <literal>jsonb_ops</literal>