Skip to content

Commit

Permalink
Traduction queries pour 9.1
Browse files Browse the repository at this point in the history
  • Loading branch information
@marco44
marco44 committed May 27, 2011
1 parent 74aafe1 commit 58d82c4
Showing 1 changed file with 105 additions and 105 deletions.
210 changes: 105 additions & 105 deletions postgresql/queries.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1523,23 +1523,25 @@ SELECT 3, 'trois';
</indexterm>

<para>
<literal>WITH</literal> provides a way to write auxiliary statements for use in a
larger query. These statements, which are often referred to as Common
Table Expressions or <acronym>CTE</acronym>s, can be thought of as defining
temporary tables that exist just for one query. Each auxiliary statement
in a <literal>WITH</literal> clause can be a <command>SELECT</command>,
<command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command>; and the
<literal>WITH</literal> clause itself is attached to a primary statement that can
also be a <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>, or
<command>DELETE</command>.
<literal>WITH</literal> fournit un moyen d'écrire des ordres
auxiliaires pour les util ser dans des requêtes plus importantes. Ces
requêtes, qui sont souvent appelées Common Table Expressions ou
<acronym>CTE</acronym>, peuvent être vues comme des tables temporaires
qui n'existent que pour une requête. Chaque ordre auxiliaire dans une
clause <literal>WITH</literal> peut être un <command>SELECT</command>,
<command>INSERT</command>, <command>UPDATE</command>, ou
<command>DELETE</command>; et la clause <literal>WITH</literal>
elle même est attachée à un ordre primaire qui peut lui aussi
être un <command>SELECT</command>, <command>INSERT</command>,
<command>UPDATE</command>, ou <command>DELETE</command>.
</para>

<sect2 id="queries-with-select">
<title><command>SELECT</command> in <literal>WITH</literal></title>
<title><command>SELECT</command> dans <literal>WITH</literal></title>

<para>
The basic value of <command>SELECT</command> in <literal>WITH</literal> is to
break down complicated queries into simpler parts. An example is:
L'intérêt de <command>SELECT</command> dans <literal>WITH</literal> est de
diviser des requêtes complexes en parties plus simples. Un exemple est:

<programlisting>WITH ventes_regionales AS (
SELECT region, SUM(montant) AS ventes_totales
Expand All @@ -1560,11 +1562,13 @@ GROUP BY region, produit;</programlisting>

qui affiche les totaux de ventes par produit dans seulement les régions
ayant les meilleures ventes.
The <literal>WITH</literal> clause defines two auxiliary statements named
<structname>regional_sales</structname> and <structname>top_regions</structname>,
where the output of <structname>regional_sales</structname> is used in
<structname>top_regions</structname> and the output of <structname>top_regions</structname>
is used in the primary <command>SELECT</command> query.
La clause <literal>WITH</literal> définit deux ordres
auxiliaires appelés <structname>ventes_regionales</structname>
et <structname>meilleures_regions</structname>, où la sortie
de <structname>ventes_regionales</structname> est utilisé dans
<structname>meilleures_regions</structname> et la sortie de
<structname>meilleures_regions</structname> est utilisée dans la
requête <command>SELECT</command> primaire.
Cet exemple aurait pu être écrit sans
<literal>WITH</literal>, mais aurait alors nécessité deux niveaux de
sous-SELECT imbriqués. Les choses sont un peu plus faciles à suivre de cette
Expand Down Expand Up @@ -1784,9 +1788,8 @@ SELECT n FROM t LIMIT 100;
est déconseillée parce que d'autres systèmes pourraient fonctionner différemment.
Par ailleurs, cela ne fonctionnera pas si vous demandez à la requête externe
de trier les résultats de la requête récursive, ou si vous les joignez à une
autre table, because in such cases the
outer query will usually try to fetch all of the <literal>WITH</literal> query's
output anyway
autre table, parce dans ces cas, la requête exterieure essaiera habituellement
de récupérer toute la sortie de la requête <literal>WITH</literal> de toutes façons.
</para>

<para>
Expand All @@ -1808,63 +1811,62 @@ SELECT n FROM t LIMIT 100;
</para>

<para>
The examples above only show <literal>WITH</literal> being used with
<command>SELECT</command>, but it can be attached in the same way to
<command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command>.
In each case it effectively provides temporary table(s) that can
be referred to in the main command.
Les exemples précédents ne montrent que des cas d'utilisation de <literal>WITH</literal>
avec <command>SELECT</command>, mais on peut les attacher de la même façon à un
<command>INSERT</command>, <command>UPDATE</command>, ou <command>DELETE</command>.
Dans chaque cas, le mécanisme fournit en fait des tables temporaires auxquelles on
peut faire référence dans la commande principale.
</para>
</sect2>

<sect2 id="queries-with-modifying">
<title>Data-Modifying Statements in <literal>WITH</literal></title>
<title>Ordres de Modification de Données avec <literal>WITH</literal></title>

<para>
You can use data-modifying statements (<command>INSERT</command>,
<command>UPDATE</command>, or <command>DELETE</command>) in <literal>WITH</literal>. This
allows you to perform several different operations in the same query.
An example is:
Vous pouvez utiliser des ordres de modification de données (<command>INSERT</command>,
<command>UPDATE</command>, ou <command>DELETE</command>) dans <literal>WITH</literal>. Cela
vous permet d'effectuer plusieurs opérations différentes dans la même requête.
Par exemple:

<programlisting>
WITH moved_rows AS (
DELETE FROM products
WITH lignes_deplacees AS (
DELETE FROM produits
WHERE
"date" &gt;= '2010-10-01' AND
"date" &lt; '2010-11-01'
RETURNING *
)
INSERT INTO products_log
SELECT * FROM moved_rows;
INSERT INTO log_produits
SELECT * FROM lignes_deplacees;
</programlisting>

This query effectively moves rows from <structname>products</structname> to
<structname>products_log</structname>. The <command>DELETE</command> in <literal>WITH</literal>
deletes the specified rows from <structname>products</structname>, returning their
contents by means of its <literal>RETURNING</literal> clause; and then the
primary query reads that output and inserts it into
<structname>products_log</structname>.
Cette requête déplace les enregistrements de <structname>produits</structname> vers
<structname>log_produits</structname>. Le <structname>DELETE</command> du <literal>WITH</literal>
supprime les enregistrements spécifiés de <structname>produits</structname>, en retournant leurs
contenus par la clause <literal>RETURNING</literal>; puis la requête primaire lit cette sortie et
l'insère dans <structname>log_produits</structname>.
</para>

<para>
A fine point of the above example is that the <literal>WITH</literal> clause is
attached to the <command>INSERT</command>, not the sub-<command>SELECT</command> within
the <command>INSERT</command>. This is necessary because data-modifying
statements are only allowed in <literal>WITH</literal> clauses that are attached
to the top-level statement. However, normal <literal>WITH</literal> visibility
rules apply, so it is possible to refer to the <literal>WITH</literal>
statement's output from the sub-<command>SELECT</command>.
Un point important à noter de l'exemple précédent est que la clause <literal>WITH</literal>
est attachée à l'<command>INSERT</command>, pas au sous-<command>SELECT</command> de l'
<command>INSERT</command>. C'est nécessaire parce que les ordres de modification de données
ne sont autorisés que dans les clauses <literal>WITH</literal> qui sont attachées à l'ordre de
plus haut niveau. Toutefois, les règles de visibilité normales de <literal>WITH</literal>
s'appliquent, il est donc possible de faire référence à la sortie du <literal>WITH</literal>
dans le sous-<command>SELECT</command>.
</para>

<para>
Data-modifying statements in <literal>WITH</literal> usually have
<literal>RETURNING</literal> clauses, as seen in the example above.
It is the output of the <literal>RETURNING</literal> clause, <emphasis>not</emphasis> the
target table of the data-modifying statement, that forms the temporary
table that can be referred to by the rest of the query. If a
data-modifying statement in <literal>WITH</literal> lacks a <literal>RETURNING</literal>
clause, then it forms no temporary table and cannot be referred to in
the rest of the query. Such a statement will be executed nonetheless.
A not-particularly-useful example is:
Les ordres de modification de données dans <literal>WITH</literal> ont habituellement
des clauses <literal>RETURNING</literal>, comme dans l'exemple précédent.
C'est la sortie de la clause <literal>RETURNING</literal> <emphasis>pas</emphasis> la
table cible de l'ordre de modification de données, qui forme la table temporaire à laquelle
on pourra faire référence dans le reste de la requête. Si un ordre de
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):

<programlisting>
WITH t AS (
Expand All @@ -1873,90 +1875,88 @@ WITH t AS (
DELETE FROM bar;
</programlisting>

This example would remove all rows from tables <structname>foo</structname> and
<structname>bar</structname>. The number of affected rows reported to the client
would only include rows removed from <structname>bar</structname>.
Cet exemple supprimerait tous les éléments des tables <structname>foo</structname> et
<structname>bar</structname>. Le nombre d'enregistrements retourné au client n'incluerait
que les enregistrements supprimés de <structname>bar</structname>.
</para>

<para>
Recursive self-references in data-modifying statements are not
allowed. In some cases it is possible to work around this limitation by
referring to the output of a recursive <literal>WITH</literal>, for example:
Les auto-références récursives dans les ordres de modification de données ne
sont pas autorisées. Dans certains cas, il est possible de contourner cette limitation
en faisant référence à la sortie d'un <literal>WITH</literal>, par exemple:

<programlisting>
WITH RECURSIVE included_parts(sub_part, part) AS (
SELECT sub_part, part FROM parts WHERE part = 'our_product'
WITH RECURSIVE pieces_incluses(sous_piece, piece) AS (
SELECT sous_piece, piece FROM pieces WHERE piece = 'notre_produit'
UNION ALL
SELECT p.sub_part, p.part
FROM included_parts pr, parts p
WHERE p.part = pr.sub_part
SELECT p.sous_piece, p.piece
FROM pieces_incluses pr, pieces p
WHERE p.piece = pr.sous_piece
)
DELETE FROM parts
WHERE part IN (SELECT part FROM included_parts);
DELETE FROM pieces
WHERE piece IN (SELECT piece FROM pieces_incluses);
</programlisting>

This query would remove all direct and indirect subparts of a product.
Cette requête supprimerait toutes les pièces directes et indirectes d'un produit.
</para>

<para>
Data-modifying statements in <literal>WITH</literal> are executed exactly once,
and always to completion, independently of whether the primary query
reads all (or indeed any) of their output. Notice that this is different
from the rule for <command>SELECT</command> in <literal>WITH</literal>: as stated in the
previous section, execution of a <command>SELECT</command> is carried only as far
as the primary query demands its output.
Les ordres de modification de données dans <literal>WITH</literal> sont exécutées exactement
une fois, et toujours jusqu'à la fin, indépendamment du fait que la requête primaire
lise tout (ou même une partie) de leur sortie. Notez que c'est différent de la règle pour
<command>SELECT</command> dans <literal>WITH</literal>: comme précisé dans la section précédente,
l'exécution d'un <command>SELECT</command> est n'est poursuivie que tant que la requête primaire
consomme sa sortie.
</para>

<para>
The sub-statements in <literal>WITH</literal> are executed concurrently with
each other and with the main query. Therefore, when using data-modifying
statements in <literal>WITH</literal>, the order in which the specified updates
actually happen is unpredictable. All the statements are executed with
the same <firstterm>snapshot</firstterm> (see <xref linkend="mvcc"/>), so they
cannot <quote>see</quote> each others' effects on the target tables. This
alleviates the effects of the unpredictability of the actual order of row
updates, and means that <literal>RETURNING</literal> data is the only way to
communicate changes between different <literal>WITH</literal> sub-statements and
the main query. An example of this is that in
Les sous-requêtes du <literal>WITH</literal> sont toutes exécutées simultanément et
simultanément avec la requête principale. Par conséquent, quand vous utilisez un ordre de
modification de données avec <literal>WITH</literal>, l'ordre dans lequel les mises à jour
sont effectuées n'est pas prévisible. Toutes les requêtes sont exécutées dans le même
<firstterm>instantané</firstterm> (voyez <xref linkend="mvcc" />), elles ne peuvent donc pas
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éntes sous-requêtes
<literal>WITH</literal> et la requête principale. En voici un exemple:

<programlisting>
WITH t AS (
UPDATE products SET price = price * 1.05
UPDATE produits SET prix = prix * 1.05
RETURNING *
)
SELECT * FROM products;
SELECT * FROM produits;
</programlisting>

the outer <command>SELECT</command> would return the original prices before the
action of the <command>UPDATE</command>, while in
le <command>SELECT</command> externe retournerait les prix originaux avant
l'action de <command>UPDATE</command>, alors que

<programlisting>
WITH t AS (
UPDATE products SET price = price * 1.05
UPDATE produits SET prix = prix * 1.05
RETURNING *
)
SELECT * FROM t;
</programlisting>

the outer <command>SELECT</command> would return the updated data.
le <command>SELECT</command> externe retournerait les données mises à jour.
</para>

<para>
Trying to update the same row twice in a single statement is not
supported. Only one of the modifications takes place, but it is not easy
(and sometimes not possible) to reliably predict which one. This also
applies to deleting a row that was already updated in the same statement:
only the update is performed. Therefore you should generally avoid trying
to modify a single row twice in a single statement. In particular avoid
writing <literal>WITH</literal> sub-statements that could affect the same rows
changed by the main statement or a sibling sub-statement. The effects
of such a statement will not be predictable.
Essayer de mettre à jour le même enregistrement deux fois dans le même ordre
n'est pas supporté. Seule une des deux modifications a lieu, mais il n'est pas
aisé (et quelquefois pas possible) de déterminer laquelle. Ceci s'applique aussi
pour la suppression d'un enregistrement qui a déjà été mis à jour dans le même ordre:
seule la mise à jour est effectuée. Par conséquent, vous devriez éviter en règle
générale de mettre à jour le même enregistrement deux fois en un seul ordre. En
particulier, évitez d'écrire des sous-requêtes qui modifieraient les mêmes enregistrements
que la requête principale ou une autre sous-requête. Les effets d'un ordre de ce type seraient
imprévisibles.
</para>

<para>
At present, any table used as the target of a data-modifying statement in
<literal>WITH</literal> must not have a conditional rule, nor an <literal>ALSO</literal>
rule, nor an <literal>INSTEAD</literal> rule that expands to multiple statements.
À l'heure actuelle, les tables utilisées comme cibles d'un ordre modifiant les données
dans un <literal>WITH</literal> ne doivent avoir ni règle conditionnelle, ni règle
<literal>ALSO</literal>, ni une règle <literal>INSTEAD</literal> qui génère plusieurs ordres.
</para>

</sect2>
Expand Down

0 comments on commit 58d82c4

Please sign in to comment.