Skip to content

Commit

Permalink
2 nouveaux fichiers traduits
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Aug 6, 2019
1 parent 66f9c70 commit 8cedbfe
Show file tree
Hide file tree
Showing 2 changed files with 67 additions and 62 deletions.
56 changes: 30 additions & 26 deletions postgresql/extend.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -678,7 +678,7 @@
<para>
Les utilisateurs souhaitent souvent charger les objets d'une extension
dans un schéma différent de celui imposé par l'auteur. Trois niveaux
de déplacement sont supportés :
de déplacement sont supportés&nbsp;:
</para>

<itemizedlist>
Expand Down Expand Up @@ -898,7 +898,7 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
</para>

<para>
Le mécanisme de mise à jour peut être utilisé pour résoudre un cas particulier important :
Le mécanisme de mise à jour peut être utilisé pour résoudre un cas particulier important&nbsp;:
convertir une collection éparse d'objets en une extension.
Avant que le mécanisme d'extension ne soit introduit à <productname>PostgreSQL</productname>
(dans la version 9.1), de nombreuses personnes écrivaient des modules d'extension qui créaient
Expand Down Expand Up @@ -1318,7 +1318,7 @@ include $(PGXS)
<term><varname>ISOLATION</varname></term>
<listitem>
<para>
list of isolation test cases, see below for more details
Liste de cas de tests d'isolation, voir ci-dessous pour plus de détails
</para>
</listitem>
</varlistentry>
Expand All @@ -1327,7 +1327,7 @@ include $(PGXS)
<term><varname>ISOLATION_OPTS</varname></term>
<listitem>
<para>
additional switches to pass to
Options supplémentaires pour réussir
<application>pg_isolation_regress</application>
</para>
</listitem>
Expand All @@ -1337,7 +1337,8 @@ include $(PGXS)
<term><varname>TAP_TESTS</varname></term>
<listitem>
<para>
switch defining if TAP tests need to be run, see below
Option définissant si les tests TAP doivent être exécutées, voir
ci-dessous.
</para>
</listitem>
</varlistentry>
Expand Down Expand Up @@ -1491,30 +1492,33 @@ make VPATH=/path/to/extension/source/tree install
</para>

<para>
The scripts listed in the <varname>ISOLATION</varname> variable are used
for tests stressing behavior of concurrent session with your module, which
can be invoked by <literal>make installcheck</literal> after doing
<literal>make install</literal>. For this to work you must have a
running <productname>PostgreSQL</productname> server. The script files
listed in <varname>ISOLATION</varname> must appear in a subdirectory
named <literal>specs/</literal> in your extension's directory. These files
must have extension <literal>.spec</literal>, which must not be included
in the <varname>ISOLATION</varname> list in the makefile. For each test
there should also be a file containing the expected output in a
subdirectory named <literal>expected/</literal>, with the same stem and
extension <literal>.out</literal>. <literal>make installcheck</literal>
executes each test script, and compares the resulting output to the
matching expected file. Any differences will be written to the file
<literal>output_iso/regression.diffs</literal> in
<command>diff -c</command> format. Note that trying to run a test that is
missing its expected file will be reported as <quote>trouble</quote>, so
make sure you have all expected files.
Les scripts listés dans la variable <varname>ISOLATION</varname> sont
utilisés pour des tests sur le comportement en cas de stress dû à des
sessions concurrentes avec votre module, tests qui peuvent être invoqués
par <literal>make installcheck</literal> après avoir exécuté <literal>make
install</literal>. Pour que ceci fonctionne, vous devez avoir un serveur
<productname>PostgreSQL</productname> fonctionnel. Les fichiers scripts
listés dans <varname>ISOLATION</varname> doivent apparaître dans un
sous-répertoire nommé <literal>specs/</literal> du répertoire de votre
extension. Ces fichiers doivent avoir une extension
<literal>.spec</literal>, qui ne doit pas être incluse dans la liste
<varname>ISOLATION</varname> du makefile. Pour chaque test, il doit aussi
y avoir un fichier contenant la sortie attendue dans un sous-répertoire
nommé <literal>expected/</literal>, avec le même nom et une extension
<literal>.out</literal>. <literal>make installcheck</literal> exécute
chaque script de test et compare la sortie résultante au fichier
correspondant attendu. Toute différence sera écrite dans le fichier
<literal>output_iso/regression.diffs</literal> au format <command>diff
-c</command>. Notez qu'essayer d'exécuter un test dont le fichier attendu
manque sera rapporté comme un problème, donc assurez-vous que vous avez
tous les fichiers attendus.
</para>

<para>
<literal>TAP_TESTS</literal> enables the use of TAP tests. Data from each
run is present in a subdirectory named <literal>tmp_check/</literal>.
See also <xref linkend="regress-tap"/> for more details.
<literal>TAP_TESTS</literal> active l'utilisation des tests TAP. Les données
de chaque exécution sont présentes dans un sous-répertoire nommé
<literal>tmp_check/</literal>. Voir aussi <xref linkend="regress-tap"/>
pour plus de détails.
</para>

<tip>
Expand Down
73 changes: 37 additions & 36 deletions postgresql/queries.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1560,8 +1560,8 @@ SELECT a "value", b + c AS somme FROM ...
</para>

<indexterm>
<primary>null value</primary>
<secondary sortas="DISTINCT">in DISTINCT</secondary>
<primary>valeur null</primary>
<secondary sortas="DISTINCT">dans DISTINCT</secondary>
</indexterm>

<para>
Expand Down Expand Up @@ -2231,72 +2231,73 @@ SELECT n FROM t LIMIT 100;
</para>

<para>
However, if a <literal>WITH</literal> query is non-recursive and
side-effect-free (that is, it is a <literal>SELECT</literal> containing
no volatile functions) then it can be folded into the parent query,
allowing joint optimization of the two query levels. By default, this
happens if the parent query references the <literal>WITH</literal> query
just once, but not if it references the <literal>WITH</literal> query
more than once. You can override that decision by
specifying <literal>MATERIALIZED</literal> to force separate calculation
of the <literal>WITH</literal> query, or by specifying <literal>NOT
MATERIALIZED</literal> to force it to be merged into the parent query.
The latter choice risks duplicate computation of
the <literal>WITH</literal> query, but it can still give a net savings if
each usage of the <literal>WITH</literal> query needs only a small part
of the <literal>WITH</literal> query's full output.
Néanmoins, si une requête <literal>WITH</literal> est non récursive et
qu'elle est libre de tout effet de bord (autrement dit un
<literal>SELECT</literal> ne contenant aucune fonction volatile), alors
elle peut être intégrée dans la requête parent, permettant ainsi une
optimisation de la joitnure sur les deux niveaux de la requête. Par défaut,
ceci survient si la requête parente fait référence une seule fois à la
requête <literal>WITH</literal> mais si elle y fait référence plusieurs
fois. Vous pouvez surcharger cette décision en indiquant
<literal>MATERIALIZED</literal> pour forcer un calcul séparé de la requête
<literal>WITH</literal> ou en spécifiant <literal>NOT
MATERIALIZED</literal> pour la forcer pour être intégrée dans la requête
parente. Ce dernier choix risque de dupliquer des calculs sur la requête
<literal>WITH</literal>, mais cela peut apporter un gain net si chaque
utilisation de la requête <literal>WITH</literal> ne nécessite qu'une
petite partie de la sortie complète de la requête <literal>WITH</literal>.
</para>

<para>
A simple example of these rules is
Un exemple simple de ces règles est le suivant&nbsp;:
<programlisting>
WITH w AS (
SELECT * FROM big_table
)
SELECT * FROM w WHERE key = 123;
</programlisting>
This <literal>WITH</literal> query will be folded, producing the same
execution plan as
Cette requête <literal>WITH</literal> va être intégrée, produisant le même
plan d'exécution que&nbsp;:
<programlisting>
SELECT * FROM big_table WHERE key = 123;
</programlisting>
In particular, if there's an index on <structfield>key</structfield>,
it will probably be used to fetch just the rows having <literal>key =
123</literal>. On the other hand, in
EN particulier, s'il existe un index sur <structfield>key</structfield>, il
sera probablement utilisé pour récupérer les lignes pour lesquelles
<literal>key = 123</literal>. D'un autre côté, dans
<programlisting>
WITH w AS (
SELECT * FROM big_table
)
SELECT * FROM w AS w1 JOIN w AS w2 ON w1.key = w2.ref
WHERE w2.key = 123;
</programlisting>
the <literal>WITH</literal> query will be materialized, producing a
temporary copy of <structname>big_table</structname> that is then
joined with itself &mdash; without benefit of any index. This query
will be executed much more efficiently if written as
la requête <literal>WITH</literal> sera matérialisée, produisant une copie
temporaire de <structname>big_table</structname> qui est ensuite jointe avec
elle-même &mdash; sans intérêt pour un index. Cette requête sera exécutée
bien plus efficacement s'il est écrite ainsi&nbsp;:
<programlisting>
WITH w AS NOT MATERIALIZED (
SELECT * FROM big_table
)
SELECT * FROM w AS w1 JOIN w AS w2 ON w1.key = w2.ref
WHERE w2.key = 123;
</programlisting>
so that the parent query's restrictions can be applied directly
to scans of <structname>big_table</structname>.
pour que les restrictions de la requête parent puissent être appliquées
directement aux parcours de <structname>big_table</structname>.
</para>

<para>
An example where <literal>NOT MATERIALIZED</literal> could be
undesirable is
Voici un exemple où <literal>NOT MATERIALIZED</literal> pourrait être
indésirable&nbsp;:
<programlisting>
WITH w AS (
SELECT key, very_expensive_function(val) as f FROM some_table
)
SELECT * FROM w AS w1 JOIN w AS w2 ON w1.f = w2.f;
</programlisting>
Here, materialization of the <literal>WITH</literal> query ensures
that <function>very_expensive_function</function> is evaluated only
once per table row, not twice.
Ici, la matérialisation de la requête <literal>WITH</literal> assure que
la <function>very_expensive_function</function> est évaluée uniquement
une fois par ligne de table, et non pas deux fois.
</para>

<para>
Expand Down Expand Up @@ -2355,7 +2356,7 @@ SELECT * FROM lignes_deplacees;
modification de données dans <literal>WITH</literal> n'a pas de clause <literal>RETURNING</literal>,
alors il ne produit pas de table temporaire et ne peut pas être utilisé dans le reste de la requête.
Un ordre de ce type sera toutefois exécuté.
En voici un exemple (dénué d'intérêt):
En voici un exemple (dénué d'intérêt)&nbsp;:

<programlisting>
WITH t AS (
Expand Down Expand Up @@ -2406,7 +2407,7 @@ DELETE FROM pieces
voir les effets des autres sur les tables cibles. Ceci rend sans importance le problème de
l'imprévisibilité de l'ordre des mises à jour, et signifie que <literal>RETURNING</literal> est
la seule façon de communiquer les modifications entre les différentes sous-requêtes
<literal>WITH</literal> et la requête principale. En voici un exemple:
<literal>WITH</literal> et la requête principale. En voici un exemple&nbsp;:

<programlisting>
WITH t AS (
Expand All @@ -2417,7 +2418,7 @@ SELECT * FROM produits;
</programlisting>

Le <command>SELECT</command> externe retournerait les prix originaux avant
l'action de <command>UPDATE</command>, alors qu'avec &nbsp;:
l'action de <command>UPDATE</command>, alors qu'avec&nbsp;:

<programlisting>
WITH t AS (
Expand Down

0 comments on commit 8cedbfe

Please sign in to comment.