root/traduc/trunk/postgresql/queries.xml

<?xml version="1.0" encoding="ISO-8859-15"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<chapter id="queries">
 <title>Requêtes</title>

 <indexterm zone="queries">
  <primary>requête</primary>
 </indexterm>

 <indexterm zone="queries">
  <primary>SELECT</primary>
 </indexterm>

 <para>
  Les précédents chapitres ont expliqué comme créer des tables, comment 
  les remplir avec des données et comment manipuler ces données.
  Maintenant, nous discutons enfin de la façon de récupérer ces données
  depuis la base de données.
 </para>


 <sect1 id="queries-overview">
  <title>Aperçu</title>

  <para>
   Le processus et la commande de récupération des données sont appelés une
   <firstterm>requête</firstterm>. En SQL, la commande <xref linkend="sql-select"
   endterm="sql-select-title"/> est utilisée pour spécifier des requêtes. La
   syntaxe générale de la commande <command>SELECT</command> est
<synopsis>
<optional>WITH <replaceable>with_requêtes</replaceable></optional> SELECT <replaceable>liste_select</replaceable> FROM <replaceable>expression_table</replaceable> <optional><replaceable>specification_tri</replaceable></optional>
</synopsis>
   Les sections suivantes décrivent le détail de la liste de sélection,
   l'expression des tables et la spécification du tri. Les requêtes
   <literal>WITH</literal> sont traitées en dernier car il s'agit d'une
   fonctionnalité avancée.
  </para>

  <para>
   Un type de requête simple est de la forme&nbsp;:
<programlisting>SELECT * FROM table1;</programlisting>
  En supposant qu'il existe une table appelée <literal>table1</literal>, cette
  commande récupérera toutes les lignes et toutes les colonnes de
  <literal>table1</literal>. La méthode de récupération dépend de l'application
  cliente. Par exemple, le programme <application>psql</application> affichera
  une table, façon art ASCII, alors que les bibliothèques du client offriront 
  des fonctions d'extraction de valeurs individuelles à partir du résultat de
  la requête. <literal>*</literal> comme liste de sélection signifie que toutes
  les colonnes de l'expression de table seront récupérées. Une liste de sélection
  peut aussi être un sous-ensemble des colonnes disponibles ou effectuer 
  un calcul en utilisant les colonnes. Par exemple, si <literal>table1</literal>
  dispose des colonnes nommées <literal>a</literal>, <literal>b</literal> et <literal>c</literal> (et
  peut-être d'autres), vous pouvez lancer la requête suivante&nbsp;:
<programlisting>SELECT a, b + c FROM table1;</programlisting>
  (en supposant que <literal>b</literal> et <literal>c</literal> soient de type numérique).
  Voir la <xref linkend="queries-select-lists"/> pour plus de détails.
 </para>

 <para>
  <literal>FROM table1</literal> est un type très simple d'expression de
tables&nbsp;: il lit une seule table. En général, les expressions de tables
sont des constructions complexes de tables de base, de jointures et de
sous-requêtes. Mais vous pouvez aussi entièrement omettre l'expression de table
et utiliser la commande <command>SELECT</command> comme une calculatrice&nbsp;:
<programlisting>SELECT 3 * 4;</programlisting>
  Ceci est plus utile si les expressions de la liste de sélection renvoient des
  résultats variants. Par exemple, vous pouvez appeler une fonction de cette
  façon&nbsp;:
<programlisting>SELECT random();</programlisting>
  </para>
 </sect1>


 <sect1 id="queries-table-expressions">
  <title>Expressions de table</title>

  <indexterm zone="queries-table-expressions">
   <primary>expression de table</primary>
  </indexterm>

  <para>
   Une <firstterm>expression de table</firstterm> calcule une table.
   L'expression de table contient une clause <literal>FROM</literal> qui peut être
   suivie des clauses <literal>WHERE</literal>, <literal>GROUP BY</literal> et
   <literal>HAVING</literal>. Les expressions triviales de table font simplement
   référence à une table sur le disque, une table de base, mais des expressions
   plus complexes peuvent être utilisées pour modifier ou combiner des tables
   de base de différentes façons.
  </para>

  <para>
   Les clauses optionnelles <literal>WHERE</literal>, <literal>GROUP BY</literal> et
   <literal>HAVING</literal> dans l'expression de table spécifient un tube de
   transformations successives réalisées sur la table dérivée de la
   clause <literal>FROM</literal>. Toutes ces transformations produisent une table
   virtuelle fournissant les lignes à passer à la liste de sélection qui
   choisira les lignes à afficher de la requête.
  </para>
        
  <sect2 id="queries-from">
   <title>Clause <literal>FROM</literal></title>
 
   <para>
    La <xref linkend="sql-from" endterm="sql-from-title"/> dérive une
    table à partir d'une ou plusieurs tables données dans une liste de
    référence dont les tables sont séparées par des virgules.
<synopsis>FROM <replaceable>reference_table</replaceable> <optional>, <replaceable>reference_table</replaceable> <optional>, ...</optional></optional></synopsis>

    Une référence de table pourrait être un nom de table (avec en option
    le nom du schéma) ou une table dérivée comme une sous-requête, une table
    jointe ou une combinaison complexe de celles-ci. Si plus d'une référence de
    tables est listée dans la clause <literal>FROM</literal>, elle sont jointes pour
    former une table virtuelle intermédiaire qui pourrait être le sujet des
    transformations des clauses <literal>WHERE</literal>, <literal>GROUP BY</literal>
    et <literal>HAVING</literal>, et est finalement le résultat des expressions de
    table.
   </para>

   <indexterm>
    <primary>ONLY</primary>
   </indexterm>

   <para>
    Lorsqu'une référence de table nomme une table qui est la table parent d'une
    table suivant la hiérarchie de l'héritage, la référence de table produit les
    lignes non seulement de la table mais aussi des descendants de cette table
    sauf si le mot clé <literal>ONLY</literal> précède le nom de la table. Néanmoins,
    la référence produit seulement les colonnes qui apparaissent dans la table
    nommée... toute colonne ajoutée dans une sous-table est ignorée.
   </para>

   <sect3 id="queries-join">
    <title>Tables jointes</title>

    <indexterm zone="queries-join">
     <primary>join</primary>
    </indexterm>

    <para>
     Une table jointe est une table dérivée de deux autres tables (réelles ou
     dérivées) suivant les règles du type de jointure particulier. Les
     jointures internes (inner), externes (outer) et croisées (cross) sont
     disponibles.
    </para>

    <variablelist>
     <title>Types de jointures</title>

     <varlistentry>
      <term>Jointure croisée (cross join)</term>

      <listitem>
      <indexterm>
       <primary>jointure</primary>
       <secondary>croisée</secondary>
      </indexterm>

      <indexterm>
       <primary>join</primary>
       <secondary>cross</secondary>
      </indexterm>

      <indexterm>
       <primary>jointure croisée</primary>
      </indexterm>

      <indexterm>
       <primary>crossed joind</primary>
      </indexterm>

<synopsis><replaceable>T1</replaceable> CROSS JOIN <replaceable>T2</replaceable></synopsis>

       <para>
        Pour chaque combinaison possible de lignes provenant de
        <replaceable>T1</replaceable> et <replaceable>T2</replaceable>
        (c'est-à-dire un produit cartésien), la table jointe contiendra
        une ligne disposant de toutes les colonnes de
        <replaceable>T1</replaceable> suivies par toutes les colonnes de
        <replaceable>T2</replaceable>.
        Si les tables ont respectivement N et M lignes, la table jointe en
        aura N * M.
       </para>

       <para>
        <literal>FROM <replaceable>T1</replaceable> CROSS JOIN
        <replaceable>T2</replaceable></literal> est équivalent à
        <literal>FROM <replaceable>T1</replaceable>,
        <replaceable>T2</replaceable></literal>.  C'est aussi équivalent à
        <literal>FROM <replaceable>T1</replaceable> INNER JOIN
        <replaceable>T2</replaceable> ON TRUE</literal> (voir ci-dessous).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Jointures qualifiées (qualified joins)</term>

      <listitem>

      <indexterm>
       <primary>join</primary>
       <secondary>outer</secondary>
      </indexterm>

      <indexterm>
       <primary>outer join</primary>
      </indexterm>

      <indexterm>
       <primary>jointure</primary>
       <secondary>externe</secondary>
      </indexterm>

      <indexterm>
       <primary>jointure externe</primary>
      </indexterm>

<synopsis><replaceable>T1</replaceable> { <optional>INNER</optional> | { LEFT | RIGHT | FULL } <optional>OUTER</optional> } JOIN <replaceable>T2</replaceable> ON <replaceable>expression_booleenne</replaceable>
<replaceable>T1</replaceable> { <optional>INNER</optional> | { LEFT | RIGHT | FULL } <optional>OUTER</optional> } JOIN <replaceable>T2</replaceable> USING ( <replaceable>liste des colonnes jointes</replaceable> )
<replaceable>T1</replaceable> NATURAL { <optional>INNER</optional> | { LEFT | RIGHT | FULL } <optional>OUTER</optional> } JOIN <replaceable>T2</replaceable></synopsis>

       <para>
        Les mots <literal>INNER</literal> et
        <literal>OUTER</literal> sont optionnels dans toutes les formes.
        <literal>INNER</literal> est la valeur par défaut&nbsp;;
        <literal>LEFT</literal>, <literal>RIGHT</literal> et
        <literal>FULL</literal> impliquent une jointure externe.
       </para>

       <para>
        La <firstterm>condition de la jointure</firstterm> est spécifiée dans
        la clause <literal>ON</literal> ou <literal>USING</literal>, ou implicitement par le
        mot <literal>NATURAL</literal>. La condition de jointure détermine les lignes
        des deux tables source considérées comme <quote>correspondante</quote>,
        comme l'explique le paragraphe ci-dessous.
       </para>

       <para>
        La clause <literal>ON</literal> est le type le plus général de condition de 
        jointure&nbsp;: il prend une expression booléenne du même genre que
        celle utilisée dans une clause <literal>WHERE</literal>. Une paires de lignes
        de <replaceable>T1</replaceable> et <replaceable>T2</replaceable> correspondent si
        l'expression <literal>ON</literal> est évaluée à vraie (true) pour ces deux
        lignes.
       </para>

       <para>
        <literal>USING</literal> est la notation raccourcie&nbsp;: elle prend une
        liste de noms de colonnes, séparés par des virgules, que les tables
        jointes ont en commun, et forme une condition de jointure spécifiant
        l'égalité de chacune de ces paires de colonnes. De plus, la sortie de
        <literal>JOIN USING</literal> a une colonne pour chaque paires égales des
        colonnes en entrée, suivies par toutes les autres colonnes de chaque
        table. Du coup, <literal>USING (a, b, c)</literal> est équivalent à
        <literal>ON (t1.a = t2.a AND t1.b = t2.b AND t1.c = t2.c)</literal> avec
        l'exception que si <literal>ON</literal> est utilisé, il y aura deux colonnes
        <literal>a</literal>, <literal>b</literal>, puis <literal>c</literal> dans le résultat, alors
        qu'avec <literal>USING</literal>, il n'y en aurait eu qu'une de chaque
        (et elles apparaîtront en premier si <command>SELECT *</command> est
        utilisé).
       </para>

       <para>
        <indexterm>
         <primary>join</primary>
         <secondary>natural</secondary>
        </indexterm>
        <indexterm>
         <primary>natural join</primary>
        </indexterm>
        <indexterm>
         <primary>jointure</primary>
         <secondary>naturelle</secondary>
        </indexterm>
        <indexterm>
         <primary>jointure naturelle</primary>
        </indexterm>
        Enfin, <literal>NATURAL</literal> est un format raccourci de
        <literal>USING</literal>&nbsp;: il forme une liste <literal>USING</literal>
        consistant de tous les noms de colonnes apparaissant à la fois dans
        les deux tables en entrée. Comme avec <literal>USING</literal>, ces colonnes
        apparaissent seulement une fois dans la table de sortie.
       </para>

       <para>
        Les types possibles de jointures qualifiées sont&nbsp;:

       <variablelist>
        <varlistentry>
         <term><literal>INNER JOIN</literal></term>

         <listitem>
          <para>
           Pour chaque ligne R1 de T1, la table jointe a une ligne pour chaque
           ligne de T2 satisfaisant la condition de jointure avec R1.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry>
         <term><literal>LEFT OUTER JOIN</literal></term>

         <listitem>
         <indexterm>
          <primary>join</primary>
          <secondary>left</secondary>
         </indexterm>

         <indexterm>
          <primary>left join</primary>
         </indexterm>

         <indexterm>
          <primary>jointure</primary>
          <secondary>gauche</secondary>
         </indexterm>

         <indexterm>
          <primary>jointure gauche</primary>
         </indexterm>

          <para>
           Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
           ligne de T1 qui ne satisfait pas la condition de jointure avec
           les lignes de T2, une ligne jointe est ajoutée avec des valeurs
           NULL dans les colonnes de T2. Du coup, la table jointe a toujours au moins
           une ligne pour chaque ligne de T1 quelque soient les conditions.
          </para>
         </listitem>
        </varlistentry>
         
        <varlistentry>
         <term><literal>RIGHT OUTER JOIN</literal></term>

         <listitem>
         <indexterm>
          <primary>join</primary>
          <secondary>right</secondary>
         </indexterm>

         <indexterm>
          <primary>right join</primary>
         </indexterm>

         <indexterm>
          <primary>jointure</primary>
          <secondary>droite</secondary>
         </indexterm>

         <indexterm>
          <primary>jointure droite</primary>
         </indexterm>

          <para>
           Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
           ligne de T2 qui ne satisfait pas la condition de jointure avec les
           lignes de T1, une ligne jointe est ajoutée avec des valeurs NULL
           dans les colonnes de T1. C'est l'inverse d'une jointure gauche&nbsp;:
           la table résultante aura toujours une ligne pour chaque ligne de T2 quelque
           soient les conditions.
          </para>
         </listitem>
        </varlistentry>
         
        <varlistentry>
         <term><literal>FULL OUTER JOIN</literal></term>

         <listitem>
          <para>
           Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
           ligne de T1 qui ne satisfait pas la condition de jointure avec les
           lignes de T2, une ligne jointe est ajoutée avec des valeurs NULL dans
           les colonnes de T2. De plus, pour chaque ligne de T2 qui ne satisfait
           pas la condition de jointure avec les lignes de T1, une ligne jointe
           est ajoutée avec des valeurs NULL dans les colonnes de T1.
          </para>
         </listitem>
        </varlistentry>
       </variablelist>
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <para>
     Les jointures de tous les types peuvent être chaînées ensemble ou
     imbriquées&nbsp;: soit les deux soit une des deux, parmi
     <replaceable>T1</replaceable> et <replaceable>T2</replaceable>, peuvent
     être des tables. Les parenthèses peuvent être utilisées autour des clauses
     <literal>JOIN</literal> pour contrôler l'ordre de jointure. En l'absence de
     parenthèses, les clauses <literal>JOIN</literal> sont imbriquées de gauche à
     droite.
    </para>

    <para>
     Pour rassembler tout ceci, supposons que nous avons une table
     <literal>t1</literal>&nbsp;:
<programlisting> no | nom
----+------
  1 | a
  2 | b
  3 | c</programlisting>
     et une table <literal>t2</literal>&nbsp;:
<programlisting> no | valeur
----+-------
  1 | xxx
  3 | yyy
  5 | zzz</programlisting>
     nous obtenons les résultats suivants pour les différentes jointures&nbsp;:
<screen><prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 CROSS JOIN t2;</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  1 | a   |  3 | yyy
  1 | a   |  5 | zzz
  2 | b   |  1 | xxx
  2 | b   |  3 | yyy
  2 | b   |  5 | zzz
  3 | c   |  1 | xxx
  3 | c   |  3 | yyy
  3 | c   |  5 | zzz
(9 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 INNER JOIN t2 ON t1.no = t2.no;</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  3 | c   |  3 | yyy
(2 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 INNER JOIN t2 USING (no);</userinput>
 no | nom | valeur
----+-----+-------
  1 | a   | xxx
  3 | c   | yyy
(2 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 NATURAL INNER JOIN t2;</userinput>
 no | nom | valeur
----+-----+-------
  1 | a   | xxx
  3 | c   | yyy
(2 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 LEFT JOIN t2 ON t1.no = t2.no;</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  2 | b   |    |
  3 | c   |  3 | yyy
(3 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 LEFT JOIN t2 USING (no);</userinput>
 no | nom | valeur
----+-----+-------
  1 | a   | xxx
  2 | b   |
  3 | c   | yyy
(3 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 RIGHT JOIN t2 ON t1.no = t2.no;</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  3 | c   |  3 | yyy
    |     |  5 | zzz
(3 rows)

<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 FULL JOIN t2 ON t1.no = t2.no;</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  2 | b   |    |
  3 | c   |  3 | yyy
    |     |  5 | zzz
(4 rows)</screen>
    </para>

    <para>
     La condition de jointure spécifiée avec <literal>ON</literal> peut aussi contenir
     des conditions sans relation directe avec la jointure. Ceci est utile
     pour quelques requêtes mais son utilisation doit avoir été réfléchie. Par
     exemple&nbsp;:
<screen><prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 LEFT JOIN t2 ON t1.no = t2.no AND t2.valeur = 'xxx';</userinput>
 no | nom | no | valeur
----+-----+----+-------
  1 | a   |  1 | xxx
  2 | b   |    |
  3 | c   |    |
(3 rows)</screen>
     Notez que placer la restriction dans la clause <literal>WHERE</literal>
     donne un résultat différent&nbsp;:
<screen>
<prompt>=&gt;</prompt> <userinput>SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num WHERE t2.value = 'xxx';</userinput>
 num | name | num | value
-----+------+-----+-------
   1 | a    |   1 | xxx
(1 row)
</screen>
     Ceci est dû au fait qu'une restriction placée dans la clause
     <literal>ON</literal> est traitée <emphasis>avant</emphasis> la jointure
     alors qu'une restriction placée dans la clause <literal>WHERE</literal>
     est traitée <emphasis>après</emphasis> la jointure.
    </para>
   </sect3>

   <sect3 id="queries-table-aliases">
    <title>Alias de table et de colonne</title>

    <indexterm zone="queries-table-aliases">
     <primary>alias</primary>
     <secondary>dans la clause FROM</secondary>
    </indexterm>

    <indexterm>
     <primary>label</primary>
     <see>alias</see>
    </indexterm>

    <para>
     Un nom temporaire peut être donné aux tables et aux références de tables
     complexe, qui sera ensuite utilisé pour référencer la table dérivée dans la
     suite de la requête. Cela s'appelle un <firstterm>alias de
     table</firstterm>.
    </para>

    <para>
     Pour créer un alias de table, écrivez
<synopsis>FROM <replaceable>reference_table</replaceable> AS <replaceable>alias</replaceable></synopsis>
     ou
<synopsis>FROM <replaceable>reference_table</replaceable> <replaceable>alias</replaceable></synopsis>
     Le mot clé <literal>AS</literal> n'est pas obligatoire.
     <replaceable>alias</replaceable> peut être tout identifiant.
    </para>

    <para>
     Une application typique des alias de table est l'affectation d'identifieurs
     courts pour les noms de tables longs, ce qui permet de garder des clauses de
     jointures lisibles. Par exemple&nbsp;:
<programlisting>SELECT * FROM nom_de_table_tres_tres_long s
  JOIN un_autre_nom_tres_long a ON s.id = a.no;</programlisting>
    </para>

    <para>
     L'alias devient le nouveau nom de référence de la table pour la requête
     courante &mdash; il n'est plus possible de référencer la table avec son nom
     d'origine. Du coup&nbsp;:
<programlisting>SELECT * FROM ma_table AS m WHERE ma_table.a &gt; 5;</programlisting>
     n'est pas valide suivant le standard SQL. Dans
     <productname>PostgreSQL</productname>, ceci amènera une erreur si la variable
     <xref linkend="guc-add-missing-from"/> est désactivée (<literal>off</literal>,
     valeur par défaut).
     S'il est activé (<literal>on</literal>), une référence vers une table
     implicite sera ajoutée à la clause <literal>FROM</literal>, de façon à ce que
     la requête soit exécutée comme si elle était écrite ainsi&nbsp;:
<programlisting>SELECT * FROM ma_table AS m, ma_table AS ma_table WHERE ma_table.a &gt; 5;</programlisting>
     Cela résultera en une jointure croisée, ce qui n'est habituellement pas
     ce que vous voulez.
    </para>

    <para>
     Les alias de table sont disponibles principalement pour aider à l'écriture
     de requête mais ils deviennent nécessaires pour joindre une table avec
     elle-même, par exemple&nbsp;:
<programlisting>SELECT * FROM personnes AS mere JOIN personnes AS enfant ON mere.id = enfant.mere_id;
</programlisting>
     De plus, un alias est requis si la référence de la table est une
     sous-requête (voir la <xref linkend="queries-subqueries"/>).
    </para>

    <para>
     Les parenthèses sont utilisées pour résoudre les ambiguïtés. Dans l'exemple
     suivant, la première instruction affecte l'alias <literal>b</literal> à la
     deuxième instance de <literal>ma_table</literal> mais la deuxième instruction
     affecte l'alias au résultat de la jonction&nbsp;:
<programlisting>SELECT * FROM ma_table AS a CROSS JOIN ma_table AS b ...
SELECT * FROM (ma_table AS a CROSS JOIN ma_table) AS b ...</programlisting>
    </para>

    <para>
     Une autre forme d'alias de tables donne des noms temporaires aux colonnes
     de la table ainsi qu'à la table&nbsp;:
<synopsis>FROM <replaceable>reference_table</replaceable> <optional>AS</optional> <replaceable>alias</replaceable> ( <replaceable>colonne1</replaceable> <optional>, <replaceable>colonne2</replaceable> <optional>, ...</optional></optional> )</synopsis>
     Si le nombre d'alias de colonnes spécifié est plus petit que le nombre
     de colonnes dont dispose la table réelle, les colonnes suivantes ne sont
     pas renommées. Cette syntaxe est particulièrement utile dans le cas de
     jointure avec la même table ou dans le cas de sous-requêtes.
    </para>

    <para>
     Quand un alias est appliqué à la sortie d'une clause <literal>JOIN</literal>,
     l'alias cache le nom original référencé à l'intérieur du
     <literal>JOIN</literal>. Par exemple&nbsp;:
<programlisting>SELECT a.* FROM ma_table AS a JOIN ta_table AS b ON ...</programlisting>
     est du SQL valide mais&nbsp;:
<programlisting>SELECT a.* FROM (ma_table AS a JOIN ta_table AS b ON ...) AS c</programlisting>
     n'est pas valide&nbsp; l'alias de table <literal>a</literal> n'est pas visible
     en dehors de l'alias <literal>c</literal>.
    </para>
   </sect3>

   <sect3 id="queries-subqueries">
    <title>Sous-requêtes</title>

    <indexterm zone="queries-subqueries">
     <primary>sous-requête</primary>
    </indexterm>

    <para>
     Une sous-requête spécifiant une table dérivée doit être enfermée 
     dans des parenthèses et <emphasis>doit</emphasis> se voir affecté un alias
     de table (voir la <xref linkend="queries-table-aliases"/>). Par
     exemple&nbsp;:
<programlisting>FROM (SELECT * FROM table1) AS nom_alias</programlisting>
    </para>

    <para>
     Cet exemple est équivalent à <literal>FROM table1 AS
     nom_alias</literal>. Des cas plus intéressants, qui ne peuvent pas être
     réduit à une jointure pleine, surviennent quand la sous-requête implique un
     groupement ou un agrégat.
    </para>

    <para>
     Uns sous-requête peut aussi être une liste <command>VALUES</command>&nbsp;:
<programlisting>
FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))
     AS noms(prenom, nom)
</programlisting>
     De nouveau, un alias de table est requis. Affecter des noms d'alias aux
     colonnes de la liste <command>VALUES</command> est en option mais c'est
     une bonne pratique. Pour plus d'informations, voir
     <xref linkend="queries-values"/>.
    </para>
   </sect3>

   <sect3 id="queries-tablefunctions">
    <title>Fonctions de table</title>

    <indexterm zone="queries-tablefunctions"><primary>fonction de table</primary></indexterm>

    <indexterm zone="queries-tablefunctions">
     <primary>fonction</primary>
     <secondary>dans la clause FROM</secondary>
    </indexterm>

    <para>
     Les fonctions de table sont des fonctions produisant un ensemble de
     lignes composées de types de données de base (types scalaires) ou de types
     de données composites (lignes de table). Elles sont utilisées comme une
     table, une vue ou une sous-requête de la clause <literal>FROM</literal> d'une
     requête. Les colonnes renvoyées par les fonctions de table peuvent être
     incluses dans une clause <literal>SELECT</literal>, <literal>JOIN</literal> ou
     <literal>WHERE</literal> de la même manière qu'une colonne de table, vue ou
     sous-requête.
    </para>

    <para>
     Si une fonction de table renvoie un type de données de base, la nom de la
     colonne de résultat correspond à celui de la fonction. Si la fonction
     renvoie un type composite, les colonnes résultantes ont le même nom que
     les attributs individuels du type.
    </para>

    <para>
     Une fonction de table peut avoir un alias dans la clause
     <literal>FROM</literal> mais elle peut être laissée sans alias. Si une
     fonction est utilisée dans la clause <literal>FROM</literal> sans alias, le nom de
     la fonction est utilisé comme nom de table résultante.
    </para>

    <para>
     Quelques exemples&nbsp;:
<programlisting>CREATE TABLE truc (trucid int, trucsousid int, trucnom text);

CREATE FUNCTION recuptruc(int) RETURNS SETOF foo AS $$
    SELECT * FROM truc WHERE trucid = $1;
$$ LANGUAGE SQL;

SELECT * FROM recuptruc(1) AS t1;

SELECT * FROM truc
    WHERE trucsousid IN (
                        SELECT trucsousid
                        FROM recuptruc(truc.trucid) z
                        WHERE z.trucid = truc.trucid);

CREATE VIEW vue_recuptruc AS SELECT * FROM recuptruc(1);
SELECT * FROM vue_recuptruc;</programlisting>
    </para>

    <para>
     Dans certains cas, il est utile de définir des fonctions de table pouvant
     renvoyer des ensembles de colonnes différentes suivant la façon dont elles
     sont appelées. Pour supporter ceci, la fonction de table est déclarée comme
     renvoyant le pseudotype <type>record</type>. Quand une telle fonction est
     utilisée dans une requête, la structure de ligne attendue doit être
     spécifiée dans la requête elle-même, de façon à ce que le système sache
     comment analyser et planifier la requête. Considérez cet exemple&nbsp;:
<programlisting>SELECT *
    FROM dblink('dbname=mabd', 'SELECT proname, prosrc FROM pg_proc')
      AS t1(proname nom, prosrc text)
    WHERE proname LIKE 'bytea%';</programlisting>
     La fonction <literal>dblink</literal> exécute une requête distante (voir
     <filename>contrib/dblink</filename>). Elle déclare renvoyer le type
     <type>record</type> car elle pourrait être utilisée pour tout type de requête.
     L'ensemble de colonnes réelles doit être spécifié dans la requête
     appelante de façon à ce que l'analyseur sache, par exemple, comment
     étendre <literal>*</literal>.
    </para>
   </sect3>
  </sect2>

  <sect2 id="queries-where">
   <title>Clause <literal>WHERE</literal></title>

   <indexterm zone="queries-where">
    <primary>WHERE</primary>
   </indexterm>

   <para>
    La syntaxe de la <xref linkend="sql-where" endterm="sql-where-title"/> est
<synopsis>WHERE <replaceable>condition_recherche</replaceable></synopsis>
    où <replaceable>condition_recherche</replaceable> est toute expression de
    valeur (voir la <xref linkend="sql-expressions"/>) renvoyant une valeur
    de type <type>boolean</type>.
   </para>

   <para>
    Après le traitement de la clause <literal>FROM</literal>, chaque ligne de la
    table virtuelle dérivée est vérifiée avec la condition de recherche. Si le
    résultat de la vérification est positif (true), la ligne est conservée dans
    la table de sortie, sinon (c'est-à-dire si le résultat est faux ou nul), la
    ligne est abandonnée. La condition de recherche référence typiquement au
    moins une colonne de la table générée dans la clause
    <literal>FROM</literal>&nbsp;; ceci n'est pas requis mais, dans le cas contraire,
    la clause <literal>WHERE</literal> n'aurait aucune utilité.
   </para>

   <note>
    <para>
     La condition de jointure d'une jointure interne peut être écrite soit dans
     la clause <literal>WHERE</literal> soit dans la clause <literal>JOIN</literal>. Par
     exemple, ces expressions de tables sont équivalentes&nbsp;:
<programlisting>FROM a, b WHERE a.id = b.id AND b.val &gt; 5</programlisting>
     et&nbsp;:
<programlisting>FROM a INNER JOIN b ON (a.id = b.id) WHERE b.val &gt; 5</programlisting>
     ou même peut-être&nbsp;:
<programlisting>FROM a NATURAL JOIN b WHERE b.val &gt; 5</programlisting>
     Laquelle vous utilisez est plutôt une affaire de style. La syntaxe
     <literal>JOIN</literal> dans la clause <literal>FROM</literal> n'est probablement pas
     aussi portable vers les autres systèmes de gestion de bases de données SQL,
     même si cela fait partie du standard SQL.
     Pour les jointures externes, il n'y a pas d'autres choix&nbsp;: elles
     doivent être faites dans la clause <literal>FROM</literal>. La clause
     <literal>ON</literal> ou <literal>USING</literal> d'une jointure externe n'est
     <emphasis>pas</emphasis> équivalente à une condition <literal>WHERE</literal> parce
     qu'elle détermine l'ajout de lignes (pour les lignes qui ne correspondent
     pas en entrée) ainsi que pour la suppression de lignes dans le résultat
     final.
    </para>
   </note>

   <para>
    Voici quelques exemples de clauses <literal>WHERE</literal>&nbsp;:
<programlisting>SELECT ... FROM fdt WHERE c1 &gt; 5

SELECT ... FROM fdt WHERE c1 IN (1, 2, 3)

SELECT ... FROM fdt WHERE c1 IN (SELECT c1 FROM t2)

SELECT ... FROM fdt WHERE c1 IN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10)

SELECT ... FROM fdt WHERE c1 BETWEEN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10) AND 100

SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 &gt; fdt.c1)</programlisting>
    <literal>fdt</literal> est la table dérivée dans la clause
    <literal>FROM</literal>. Les lignes qui ne correspondent pas à la condition de
    recherche de la clause <literal>WHERE</literal> sont éliminées de la table
    <literal>fdt</literal>. Notez l'utilisation de sous-requêtes scalaires en
    tant qu'expressions de valeurs. Comme n'importe quelle autre requête, les
    sous-requêtes peuvent employer des expressions de tables complexes. Notez
    aussi comment <literal>fdt</literal> est référencée dans les sous-requêtes.
    Qualifier <literal>c1</literal> comme <literal>fdt.c1</literal> est seulement nécessaire
    si <literal>c1</literal> est aussi le nom d'une colonne dans la table d'entrée
    dérivée de la sous-requête. Mais qualifier le nom de colonne ajoute à la
    clarté même lorsque cela n'est pas nécessaire. Cet exemple montre comment
    le nom de colonne d'une requête externe est étendue dans les requêtes
    internes.
   </para>
  </sect2>


  <sect2 id="queries-group">
   <title>Clauses <literal>GROUP BY</literal> et
<literal>HAVING</literal></title>

   <indexterm zone="queries-group">
    <primary>GROUP BY</primary>
   </indexterm>

   <indexterm zone="queries-group">
    <primary>groupement</primary>
   </indexterm>

   <para>
    Après avoir passé le filtre <literal>WHERE</literal>, la table d'entrée dérivée
    peut être sujette à un regroupement en utilisant la clause <literal>GROUP
    BY</literal> et à une élimination de groupe de lignes avec la clause
    <literal>HAVING</literal>.
   </para>

<synopsis>SELECT <replaceable>liste_selection</replaceable>
    FROM ...
    <optional>WHERE ...</optional>
    GROUP BY <replaceable>reference_colonne_regroupement</replaceable><optional>,<replaceable>reference_colonne_regroupement</replaceable></optional>...</synopsis>

   <para>
    La <xref linkend="sql-groupby" endterm="sql-groupby-title"/> est
    utilisée pour regrouper les lignes d'une table qui ont les mêmes valeurs
    dans toutes les colonnes précisées. L'ordre dans lequel ces colonnes sont
    indiquées importe peu. L'effet est de combiner chaque ensemble de lignes
    partageant des valeurs communes en un seul groupe de ligne représentant
    toutes les lignes du groupe. Ceci est fait pour éliminer les redondances dans
    la sortie et/ou pour calculer les agrégats s'appliquant à ces groupes. Par
    exemple&nbsp;:
<screen><prompt>=&gt;</prompt> <userinput>SELECT * FROM test1;</userinput>
 x | y
---+---
 a | 3
 c | 2
 b | 5
 a | 1
(4 rows)

<prompt>=&gt;</prompt> <userinput>SELECT x FROM test1 GROUP BY x;</userinput>
 x
---
 a
 b
 c
(3 rows)</screen>
   </para>
          
   <para>
    Dans la seconde requête, nous n'aurions pas pu écrire <literal>SELECT *
    FROM test1 GROUP BY x</literal> parce qu'il n'existe pas une seule valeur
    pour la colonne <literal>y</literal> pouvant être associé avec chaque autre groupe.
    Les colonnes de regroupement peuvent être référencées dans la liste de
    sélection car elles ont une valeur constante unique par groupe.
   </para>

   <para>
    En général, si une table est groupée, les colonnes qui ne sont pas
    listées dans le <literal>GROUP BY</literal> ne peuvent pas être référencées
    sauf dans les expressions d'agrégats. Voici un exemple d'expressions
    d'agrégat&nbsp;:
<screen><prompt>=&gt;</prompt> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x;</userinput>
 x | sum
---+-----
 a |   4
 b |   5
 c |   2
(3 rows)</screen>
    Ici, <literal>sum</literal> est la fonction d'agrégat qui calcule une seule
    valeur pour le groupe entier. La <xref linkend="functions-aggregate"/>
    propose plus d'informations sur les fonctions d'agrégats disponibles.
   </para>

   <tip>
    <para>
     Le regroupement sans expressions d'agrégats calcule effectivement
     l'ensemble les valeurs distinctes d'une colonne. Ceci peut aussi se faire
     en utilisant la clause <literal>DISTINCT</literal> (voir la <xref
     linkend="queries-distinct"/>).
    </para>
   </tip>

   <para>
    Voici un autre exemple&nbsp;: il calcule les ventes totales pour chaque
    produit (plutôt que le total des ventes sur tous les produits)&nbsp;:
<programlisting>SELECT produit_id, p.nom, (sum(v.unite) * p.prix) AS ventes
    FROM produits p LEFT JOIN ventes v USING (produit_id)
    GROUP BY produit_id, p.nom, p.prix;</programlisting>
    Dans cet exemple, les colonnes <literal>produit_id</literal>,
    <literal>p.nom</literal> et <literal>p.prix</literal> doivent être dans la
    clause <literal>GROUP BY</literal> car elles sont référencées dans la liste de
    sélection de la requête (suivant la façon dont est conçue la table
    produits, le nom et le prix pourraient être totalement dépendants de l'ID du
    produit, donc des regroupements supplémentaires pourraient théoriquement
    être inutiles mais ceci n'est pas encore implémenté). La colonne
    <literal>s.unite</literal> n'a pas besoin d'être dans la liste <literal>GROUP
    BY</literal> car elle est seulement utilisée dans l'expression de l'agrégat
    (<literal>sum(...)</literal>) représentant les ventes d'un produit. Pour
    chaque produit, la requête renvoie une ligne de résumé sur les ventes de ce
    produit.
   </para>

   <para>
    En SQL strict, <literal>GROUP BY</literal> peut seulement grouper les colonnes de
    la table source mais <productname>PostgreSQL</productname> étend ceci en
    autorisant <literal>GROUP BY</literal> à grouper aussi les colonnes de la liste de
    sélection. Grouper par expressions de valeurs au lieu de simples noms de
    colonnes est aussi permis.
   </para>

   <indexterm>
    <primary>HAVING</primary>
   </indexterm>

   <para>
    Si une table a été groupée en utilisant la clause <literal>GROUP
    BY</literal> mais que seuls certains groupes sont intéressants, la clause
    <literal>HAVING</literal> peut être utilisée, comme une clause
    <literal>WHERE</literal>, pour éliminer les groupes du résultat. Voici la
    syntaxe&nbsp;:
<synopsis>SELECT <replaceable>liste_selection</replaceable> FROM ... <optional>WHERE ...</optional> GROUP BY ... HAVING <replaceable>expression_booléenne</replaceable></synopsis>
    Les expressions de la clause <literal>HAVING</literal> peuvent référer à la fois
    aux expressions groupées et aux expressions non groupées (ce qui impliquent
    nécessairement une fonction d'agrégat).
   </para>

   <para>
    Exemple&nbsp;:
<screen><prompt>=&gt;</prompt> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x HAVING sum(y) &gt; 3;</userinput>
 x | sum
---+-----
 a |   4
 b |   5
(2 rows)

<prompt>=&gt;</prompt> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x HAVING x &lt; 'c';</userinput>
 x | sum
---+-----
 a |   4
 b |   5
(2 rows)</screen>
   </para>

   <para>
    De nouveau, un exemple plus réaliste&nbsp;:
<programlisting>SELECT produit_id, p.nom, (sum(v.unite) * (p.prix - p.cout)) AS profit
    FROM produits p LEFT JOIN ventes v USING (produit_id)
    WHERE v.date &gt; CURRENT_DATE - INTERVAL '4 weeks'
    GROUP BY produit_id, p.nom, p.prix, p.cout
    HAVING sum(p.prix * s.unite) &gt; 5000;</programlisting>
    Dans l'exemple ci-dessus, la clause <literal>WHERE</literal> sélectionne les
    lignes par une colonne qui n'est pas groupée (l'expression est vraie
    seulement pour les ventes des quatre dernières semaines) alors que la
    clause <literal>HAVING</literal> restreint la sortie aux groupes dont le total des
    ventes dépasse 5000. Notez que les expressions d'agrégats n'ont pas besoin
    d'être identiques dans toutes les parties d'une requête.
   </para>

   <para>
    Si une requête contient des appels à des fonctions d'aggrégat, mais pas
    de clause <literal>GROUP BY</literal>, le regroupement a toujours lieu&nbsp;:
    le résultat est une seule ligne de regroupement (ou peut-être pas de ligne
    du tout si la ligne unique est ensuite éliminée par la clause
    <literal>HAVING</literal>).
    Ceci est vrai aussi si elle comporte une clause <literal>HAVING</literal>,
    même sans fonction d'aggrégat ou <literal>GROUP BY</literal>.
   </para>
  </sect2>

  <sect2 id="queries-window">
   <title>Traitement de fonctions Window</title>

   <indexterm zone="queries-window">
    <primary>fonction window</primary>
    <secondary>ordre d'exécution</secondary>
   </indexterm>

   <para>
    Si la requête contient une des fonctions Window (voir
    <xref linkend="tutorial-window"/> et <xref linkend="syntax-window-functions"/>),
    ces fonctions sont évaluées après que soient effectués les regroupements,
    les aggrégations, les filtrages par <literal>HAVING</literal>.
    C'est-à-dire que si la requête comporte des aggrégat, <literal>GROUP
    BY</literal> ou <literal>HAVING</literal>, alors les enregistrements vus
    par les fonctions window sont les lignes regroupées à la place des
    enregistrements originaux provenant de 
    <literal>FROM</literal>/<literal>WHERE</literal>.
   </para>

   <para>
    Quand des fonctions Window multiples sont utilisées, toutes les fonctions
    Window ayant des clauses <literal>PARTITION BY</literal> et <literal>ORDER BY</literal>
    syntaxiquement équivalentes seront à coup sûr évaluées en une seule passe sur
    les données.
    Par conséquent, elles verront le même ordre de tri, même si
    <literal>ORDER BY</literal> ne détermine pas de façon unique un tri.
    Toutefois, aucune garantie n'est faite à propos de l'évaluation de fonctions
    ayant des spécifications de <literal>PARTITION BY</literal> ou
    <literal>ORDER BY</literal> différentes.
    (Dans ces cas, une étape de tri est généralement nécessaire entre les passes
    d'évaluations de fonctions Window, et le tri ne garantit pas la préservation
    de l'ordre des enregistrements que son <literal>ORDER BY</literal> estime
    comme identiques.)
   </para>

   <para>
    À l'heure actuelle, les fonctions window nécessitent toujours des données
    pré-triées, ce qui fait que la sortie de la requête sera triée suivant
    l'une ou l'autre des clauses <literal>PARTITION BY</literal>/<literal>ORDER BY</literal>
    des fonctions Window.
    Il n'est toutefois pas recommandé de s'en servir. Utilisez une clause
    <literal>ORDER BY</literal> au plus haut niveau de la requête si vous
    voulez être sûr que vos résultats soient triés d'une certaine façon.
   </para>
  </sect2>
 </sect1>


 <sect1 id="queries-select-lists">
  <title>Listes de sélection</title>

  <indexterm>
   <primary>SELECT</primary>
   <secondary>liste de sélection</secondary>
  </indexterm>

  <para>
   Comme montré dans la section précédente, l'expression de table pour la
commande <command>SELECT</command> construit une table virtuelle intermédiaire
en combinant les tables, vues, en éliminant les lignes, en groupant, etc. Cette
table est finalement passée à la réalisation de la <firstterm>liste de
sélection</firstterm>. Cette liste détermine les <emphasis>colonnes</emphasis>
de la table intermédiaire à afficher.
  </para>

  <sect2 id="queries-select-list-items">
   <title>Éléments de la liste de sélection</title>

   <indexterm>
    <primary>*</primary>
   </indexterm>

   <para>
    La forme la plus simple de liste de sélection est <literal>*</literal>.
    C'est un raccourci pour indiquer toutes les colonnes que l'expression de
    table produit. Sinon, une liste de sélection est une liste d'expressions
    de valeurs séparées par des virgules (comme défini dans la <xref
    linkend="sql-expressions"/>). Par exemple, cela pourrait être une liste des
    noms de colonnes&nbsp;:
<programlisting>SELECT a, b, c FROM ...</programlisting>
     Les noms de colonnes <literal>a</literal>, <literal>b</literal> et <literal>c</literal> sont
     soit les noms actuels des colonnes des tables référencées dans la clause
     <literal>FROM</literal> soit les alias qui leur ont été donnés (voir l'explication
     dans <xref linkend="queries-table-aliases"/>). L'espace de nom disponible
     dans la liste de sélection est le même que dans la clause <literal>WHERE</literal>
     sauf si le regroupement est utilisé, auquel cas c'est le même que dans la
     clause <literal>HAVING</literal>.
   </para>

   <para>
    Si plus d'une table a une colonne du même nom, le nom de la table doit
aussi être donné comme dans&nbsp;:
<programlisting>SELECT tbl1.a, tbl2.a, tbl1.b FROM ...</programlisting>
    En travaillant avec plusieurs tables, il est aussi utile de demander toutes
    les colonnes d'une table particulière&nbsp;:
<programlisting>SELECT tbl1.*, tbl2.a FROM ...</programlisting>
    (voir aussi la <xref linkend="queries-where"/>)
   </para>

   <para>
    Si une expression de valeur arbitraire est utilisée dans la liste de
    sélection, il ajoute conceptuellement une nouvelle colonne virtuelle dans la
    table renvoyée. L'expression de valeur est évaluée une fois pour chaque
    ligne avec une substitution des valeurs de lignes avec les références de
    colonnes. Mais les expressions de la liste de sélection n'ont pas à
    référencer les colonnes dans l'expression de la table de la clause
    <literal>FROM</literal>&nbsp;; elles pourrait être des expressions arithmétiques
    constantes, par exemple.
   </para>
  </sect2>

  <sect2 id="queries-column-labels">
   <title>Labels de colonnes</title>

   <indexterm zone="queries-column-labels">
    <primary>alias</primary>
    <secondary>dans la liste de sélection</secondary>
   </indexterm>

   <para>
    Les entrées de la liste de sélection peuvent se voir affecter des noms
    pour la suite de l'exécution, peut-être pour référence dans une clause
    <literal>ORDER BY</literal> ou pour affichage par l'application cliente.
    Par exemple&nbsp;:
<programlisting>SELECT a AS valeur, b + c AS sum FROM ...</programlisting>
   </para>

   <para>
    Si aucun nom de colonne en sortie n'est spécifié en utilisant
    <literal>AS</literal>, le système affecte un nom de colonne par défaut.
    Pour les références de colonne simple, c'est le nom de la colonne
    référencée. Pour les appels de fonction, il s'agit du nom de la fonction.
    Pour les expressions complexes, le système générera un nom générique.
   </para>

   <para>
    Le mot clé <literal>AS</literal> est optionnel, mais seulement si le
    nouveau nom de colonne ne correspond à aucun des mots clés
    <productname>PostgreSQL</productname> (voir <xref
    linkend="sql-keywords-appendix"/>). Pour éviter une correspondance
    accidentelle à un mot clé, vous pouvez mettre le nom de colonne entre
    guillemets. Par exemple, <literal>VALUE</literal> est un mot clé, ce qui
    fait que ceci ne fonctionne pas&nbsp;:
<programlisting>
SELECT a valeur, b + c AS somme FROM ...
</programlisting>
    mais ceci fonctionne&nbsp;:
<programlisting>
SELECT a "valeur", b + c AS somme FROM ...
</programlisting>
    Pour vous protéger de possibles ajouts futurs de mots clés, il est recommandé
    de toujours écrire <literal>AS</literal> ou de mettre le nom de colonne de
    sortie entre guillemets.
   </para>

   <note>
    <para>
     Le nom des colonnes en sortie est différent ici de ce qui est fait dans la
     clause <literal>FROM</literal> (voir la <xref linkend="queries-table-aliases"/>).
     Il est possible de renommer deux fois la même colonne mais le nom affecté
     dans la liste de sélection est celui qui sera passé.
    </para>
   </note>
  </sect2>

  <sect2 id="queries-distinct">
   <title><literal>DISTINCT</literal></title>

   <indexterm zone="queries-distinct">
    <primary>DISTINCT</primary>
   </indexterm>

   <indexterm zone="queries-distinct">
    <primary>duplication</primary>
   </indexterm>

   <para>
    Après le traitement de la liste de sélection, la table résultant pourrait
    être optionnellement sujet à l'élimination des lignes dupliquées. Le mot clé
    <literal>DISTINCT</literal> est écrit directement après
    <literal>SELECT</literal> pour spécifier ceci&nbsp;:
<synopsis>SELECT DISTINCT <replaceable>liste_selection</replaceable> ...</synopsis>
    (au lieu de <literal>DISTINCT</literal>, le mot clé <literal>ALL</literal> peut être
    utilisé pour spécifier le comportement par défaut, la récupération de
    toutes les lignes)
   </para>

   <para>
    <indexterm><primary>valeur NULL</primary><secondary sortas="DISTINCT">dans
    DISTINCT</secondary></indexterm>
    Évidemment, les deux lignes sont considérées distinctes si elles diffèrent
    dans au moins une valeur de colonne. Les valeurs NULL sont considérées
    égales dans cette comparaison.
   </para>

   <para>
    Autrement, une expression arbitraire peut déterminer quelles lignes
    doivent être considérées distinctes&nbsp;:
<synopsis>SELECT DISTINCT ON (<replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ...</optional>) <replaceable>liste_selection</replaceable> ... </synopsis>
    Ici, <replaceable>expression</replaceable> est une expression de valeur
    arbitraire, évaluée pour toutes les lignes. Les lignes dont toutes les
    expressions sont égales sont considérées comme dupliquées et seule la
    première ligne de cet ensemble est conservée dans la sortie. Notez que la
    <quote>première ligne</quote> d'un ensemble est non prévisible sauf si la
    requête est triée sur assez de colonnes pour garantir un ordre unique des
    colonnes arrivant dans le filtre <literal>DISTINCT</literal> (le traitement de
    <literal>DISTINCT ON</literal> parvient après le tri de <literal>ORDER BY</literal>).
   </para>

   <para>
    La clause <literal>DISTINCT ON</literal> ne fait pas partie du standard SQL et est
    quelque fois considérée comme étant un mauvais style à cause de la nature
    potentiellement indéterminée de ses résultats. Avec l'utilisation judicieuse
    de <literal>GROUP BY</literal> et de sous-requêtes dans <literal>FROM</literal>, la
    construction peut être évitée mais elle représente souvent l'alternative la
    plus agréable.
   </para>
  </sect2>
 </sect1>


 <sect1 id="queries-union">
  <title>Combiner des requêtes</title>

  <indexterm zone="queries-union">
   <primary>UNION</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>INTERSECT</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>EXCEPT</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>set union</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>set intersection</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>set difference</primary>
  </indexterm>
  <indexterm zone="queries-union">
   <primary>set operation</primary>
  </indexterm>

  <para>
   Les résultats de deux requêtes peuvent être combinés en utilisant les 
   opérations d'ensemble&nbsp;: union, intersection et différence. La syntaxe
   est
<synopsis><replaceable>requete1</replaceable> UNION <optional>ALL</optional> <replaceable>requete2</replaceable>
<replaceable>requete1</replaceable> INTERSECT <optional>ALL</optional> <replaceable>requete2</replaceable>
<replaceable>requete1</replaceable> EXCEPT <optional>ALL</optional> <replaceable>requete2</replaceable></synopsis>
   <replaceable>requete1</replaceable> et
   <replaceable>requete2</replaceable> sont les requêtes pouvant utiliser
   toutes les fonctionnalités discutées ici. Les opérations d'ensemble peuvent
   aussi être combinées et chaînées, par exemple
<synopsis><replaceable>requete1</replaceable> UNION <replaceable>requete2</replaceable> UNION <replaceable>requete3</replaceable></synopsis>
   est exécuté ainsi&nbsp;:
<synopsis>(<replaceable>requete1</replaceable> UNION <replaceable>requete2</replaceable>) UNION <replaceable>requete3</replaceable></synopsis>
  </para>

  <para>
   <literal>UNION</literal> ajoute effectivement le résultat de
   <replaceable>requete2</replaceable> au résultat de
   <replaceable>requete1</replaceable> (bien qu'il n'y ait pas de garantie
   qu'il s'agit de l'ordre dans lequel les lignes sont réellement renvoyées). De
   plus, il élimine les lignes dupliquées du résultat, de la même façon que
   <literal>DISTINCT</literal>, sauf si <literal>UNION ALL</literal> est utilisée.
  </para>

  <para>
   <literal>INTERSECT</literal> renvoie toutes les lignes qui sont à la fois dans le
   résultat de <replaceable>requete1</replaceable> et dans le résultat de
   <replaceable>requete2</replaceable>. Les lignes dupliquées sont éliminées
   sauf si <literal>INTERSECT ALL</literal> est utilisé.
  </para>

  <para>
   <literal>EXCEPT</literal> renvoie toutes les lignes qui sont dans le résultat de
   <replaceable>requete1</replaceable> mais pas dans le résultat de
   <replaceable>requete2</replaceable> (ceci est quelque fois appelé la
   <firstterm>différence</firstterm> entre deux requêtes). De nouveau, les lignes
   dupliquées sont éliminées sauf si <literal>EXCEPT ALL</literal> est utilisé.
  </para>

  <para>
   Pour calculer l'union, l'intersection ou la différence de deux requêtes, les
   deux requêtes doivent être <quote>compatibles pour une union</quote>, ce qui
   signifie qu'elles doivent renvoyer le même nombre de colonnes et que les
   colonnes correspondantes doivent avoir des types de données compatibles,
   comme décrit dans la <xref linkend="typeconv-union-case"/>.
  </para>
 </sect1>


 <sect1 id="queries-order">
  <title>Tri des lignes</title>

  <indexterm zone="queries-order">
   <primary>tri</primary>
  </indexterm>

  <indexterm zone="queries-order">
   <primary>ORDER BY</primary>
  </indexterm>
           
  <para>
   Après qu'une requête ait produit une table en sortie (après que la liste de
   sélection ait été traitée), elle peut être optionnellement triée. Si le tri
   n'a pas été choisi, les lignes sont renvoyées dans un ordre non spécifié.
   Dans ce cas, l'ordre réel dépendra des types de plan de parcours et de
   jointure et de l'ordre sur le disque mais vous ne devez pas vous y fier. Un
   tri particulier en sortie peut seulement être garantie si l'étape de tri est
   choisie explicitement.
  </para>

  <para>
   La clause <literal>ORDER BY</literal> spécifie l'ordre de tri&nbsp;:
<synopsis>SELECT <replaceable>liste_selection</replaceable>
    FROM <replaceable>expression_table</replaceable>
    ORDER BY <replaceable>expression_tri1</replaceable> <optional>ASC | DESC</optional> <optional>NULLS { FIRST | LAST }</optional>
<optional>, <replaceable>expression_tri2</replaceable> <optional>ASC | DESC</optional> <optional>NULLS { FIRST | LAST }</optional> ...</optional>
</synopsis>

   Les expressions de tri peuvent être toute expression qui serait valide dans
   la liste de sélection des requêtes. Voici un exemple&nbsp;:
<programlisting>
SELECT a, b FROM table1 ORDER BY a + b, c;
</programlisting>
   Quand plus d'une expression est indiquée, les valeurs suivantes sont
   utilisées pour trier les lignes qui sont identiques aux valeurs précédentes.
   Chaque expression pourrait être suivie d'un
   <literal>ASC</literal> ou <literal>DESC</literal> optionnel pour configurer la
   direction du tri (ascendant ou descendant). L'ordre <literal>ASC</literal> est la
   valeur par défaut. L'ordre ascendant place les plus petites valeurs en
   premier où <quote>plus petit</quote> est défini avec l'opérateur
   <literal>&lt;</literal>. De façon similaire, l'ordre descendant est
   déterminé avec l'opérateur <literal>&gt;</literal>.
    <footnote>
     <para>
      En fait, <productname>PostgreSQL</productname> utilise la <firstterm>classe
      d'opérateur B-tree par défaut</firstterm> pour le type de données de
      l'expression pour déterminer l'ordre de tri avec <literal>ASC</literal>
      et <literal>DESC</literal>.
      De façon conventionnelle, les types de données seront initialisés de
      façon à ce que les opérateurs <literal>&lt;</literal> et
      <literal>&gt;</literal> correspondent à cet ordre de tri mais un
      concepteur des types de données définis par l'utilisateur pourrait choisir
      de faire quelque chose de différent.
     </para>
    </footnote>
  </para>

  <para>
   Les options <literal>NULLS FIRST</literal> et <literal>NULLS LAST</literal>
   sont utilisées pour déterminer si les valeurs NULL apparaissent avant ou
   après les valeurs non NULL après un tri. Par défaut, les valeurs NULL sont
   triées comme si elles étaient plus grandes que toute valeur non NULL.
   Autrement dit, <literal>NULLS FIRST</literal> est la valeur par défaut pour
   l'ordre descendant (<literal>DESC</literal>) et <literal>NULLS LAST</literal>
   est la valeur utilisée sinon.
  </para>

  <para>
   Notez que les options de tri sont considérées indépendament pour chaque
   colonne triée. Par exemple, <literal>ORDER BY x, y DESC</literal> signifie
   en fait <literal>ORDER BY x ASC, y DESC</literal>, ce qui est différent de
   <literal>ORDER BY x DESC, y DESC</literal>.
  </para>

  <para>
   Une <replaceable>expression_tri</replaceable> peut aussi être à la place
   le nom ou le numéro d'une colonne en sortie, par exemple&nbsp;:
<programlisting>SELECT a + b AS sum, c FROM table1 ORDER BY sum;
SELECT a, max(b) FROM table1 GROUP BY a ORDER BY 1;
</programlisting>
   les deux triant par la première colonne en sortie. Notez qu'un nom de colonne
   en sortie doit être unique, il ne doit pas être utilisé dans une expression
   &mdash; par exemple, ceci n'est <emphasis>pas</emphasis> correct&nbsp;:
<programlisting>
SELECT a + b AS sum, c FROM table1 ORDER BY sum + c;          -- mauvais
</programlisting>
   Cette restriction est là pour réduire l'ambiguïté. Il y en a toujours si un
   élément <literal>ORDER BY</literal> est un simple nom qui pourrait
   correspondre soit à un nom de colonne en sortie soit à une colonne d'une
   expression de table. La colonne en sortie est utilisée dans de tels cas.
   Cela causera seulement de la confusion si vous utilisez <literal>AS</literal>
   pour renommer une colonne en sortie qui correspondra à un autre nom de
   colonne d'une table.
  </para>

  <para>
   <literal>ORDER BY</literal> peut être appliqué au résultat d'une combinaison
   <literal>UNION</literal>, d'une combinaison<literal>INTERSECT</literal> ou
   d'une combinaison <literal>EXCEPT</literal> mais, dans ce cas, il est
   seulement permis de trier par les noms ou numéros de colonnes, pas par les
   expressions.
  </para>
 </sect1>


 <sect1 id="queries-limit">
  <title><literal>LIMIT</literal> et <literal>OFFSET</literal></title>

  <indexterm zone="queries-limit">
   <primary>LIMIT</primary>
  </indexterm>

  <indexterm zone="queries-limit">
   <primary>OFFSET</primary>
  </indexterm>

  <para>
   <literal>LIMIT</literal> et <literal>OFFSET</literal> vous permet de retrouver seulement 
   une portion des lignes générées par le reste de la requête&nbsp;:
<synopsis>SELECT <replaceable>liste_selection</replaceable>
    FROM <replaceable>expression_table</replaceable>
    <optional> ORDER BY ...</optional>
    <optional> LIMIT { <replaceable>nombre</replaceable> | ALL } </optional> <optional>OFFSET <replaceable>nombre</replaceable></optional></synopsis>
  </para>

  <para>
   Si un nombre limite est donné, pas plus que ce nombre de lignes sera renvoyé
   (mais peut-être moins si la requête récupère moins de lignes). <literal>LIMIT
   ALL</literal> revient à ne pas spécifier la clause <literal>LIMIT</literal>.
  </para>

  <para>
   <literal>OFFSET</literal> indique de passer ce nombre de lignes avant de renvoyer 
   les lignes restantes. <literal>OFFSET 0</literal> revient à oublier la clause
   <literal>OFFSET</literal>, et <literal>LIMIT NULL</literal> revient à oublier
   la clause <literal>LIMIT</literal>. Si à la fois <literal>OFFSET</literal> et <literal>LIMIT</literal>
   apparaissent, alors les <literal>OFFSET</literal> lignes sont laissées avant de
   commencer le renvoi des <literal>LIMIT</literal> lignes.
  </para>

  <para>
   Lors de l'utilisation de <literal>LIMIT</literal>, il est important d'utiliser une
   clause <literal>ORDER BY</literal> contraignant les lignes résultantes dans un ordre
   unique. Sinon, vous obtiendrez un sous-ensemble non prévisible de lignes de
   la requête. Vous pourriez demander les lignes de 10 à 20 mais dans quel
   ordre&nbsp;? L'ordre est inconnu si vous ne spécifiez pas <literal>ORDER
   BY</literal>.
  </para>

  <para>
   L'optimiseur de requêtes prend <literal>LIMIT</literal> en compte lors de la
   génération des plans de requêtes, de façon à ce que vous obteniez
   différents plans (avec différents ordres de lignes) suivant ce que vous
   donnez à <literal>LIMIT</literal> et <literal>OFFSET</literal>. Du coup, utiliser des
   valeurs <literal>LIMIT</literal>/<literal>OFFSET</literal> différentes pour sélectionner
   des sous-ensembles différents d'un résultat de requête <emphasis>donnera des
   résultats inconsistants</emphasis> sauf si vous forcez un ordre de
   résultat prévisible avec <literal>ORDER BY</literal>. Ceci n'est pas un bogue&nbsp;;
   c'est une conséquence inhérente du fait que le SQL ne promette par de
   délivrer les résultats d'une requête dans un ordre particulier sauf si
   <literal>ORDER BY</literal> est utilisé pour contraindre l'ordre.
  </para>

  <para>
   Les lignes passées par une clause <literal>OFFSET</literal> devront toujours être
   traitées à l'intérieur du serveur&nbsp;; du coup, un <literal>OFFSET</literal>
   important peut être inefficace.
  </para>
 </sect1>


 <sect1 id="queries-values">
  <title>Listes <literal>VALUES</literal></title>

  <indexterm zone="queries-values">
   <primary>VALUES</primary>
  </indexterm>

  <para>
   <literal>VALUES</literal> fournit une façon de générer une table de
   <quote>constantes</quote> qui peut être utilisé dans une requête sans
   avoir à réellement créer et peupler une table sur disque. La syntaxe est
<synopsis>
VALUES ( <replaceable class="parameter">expression</replaceable> [, ...] ) [, ...]
</synopsis>
   Chaque liste d'expressions entre parenthèses génère une ligne dans la table.
   Les listes doivent toutes avoir le même nombre d'éléments (c'est-à-dire une
   liste de colonnes dans la table), et les entrées correspondantes dans chaque
   liste doivent avoir des types compatibles. Le type réel affecté à chaque colonne
   du résultat est déterminé en utilisant les mêmes règles que pour
   <literal>UNION</literal> (voir <xref linkend="typeconv-union-case"/>).
  </para>

  <para>
   Voici un exemple&nbsp;:

<programlisting>VALUES (1, 'un'), (2, 'deux'), (3, 'trois');
</programlisting>

   renverra une table de deux colonnes et trois lignes. C'est équivalent à&nbsp;:

<programlisting>SELECT 1 AS column1, 'un' AS column2
UNION ALL
SELECT 2, 'deux'
UNION ALL
SELECT 3, 'trois';
</programlisting>

   Par défaut, <productname>PostgreSQL</productname> affecte les noms
   <literal>column1</literal>, <literal>column2</literal>, etc. aux colonnes
   d'une table <literal>VALUES</literal>. Les noms des colonnes ne sont pas
   spécifiés par le standard SQL et les différents SGBD le font de façon
   différente. Donc, il est généralement mieux de surcharger les noms par
   défaut avec une liste d'alias.
  </para>

  <para>
   Syntaxiquement, <literal>VALUES</literal> suivi par une liste d'expressions
   est traité de la même façon que
<synopsis>SELECT <replaceable>liste_select</replaceable> FROM <replaceable>expression_table</replaceable>
</synopsis>
   et peut apparaître partout où un <literal>SELECT</literal> le peut. Par
   exemple, vous pouvez l'utiliser comme élément d'un <literal>UNION</literal>
   ou y attacher une <replaceable>spécification de tri</replaceable>
   (<literal>ORDER BY</literal>, <literal>LIMIT</literal> et/ou <literal>OFFSET</literal>).
   <literal>VALUES</literal> est habituellement utilisée comme source de données
   dans une commande <command>INSERT</command> command, mais aussi dans une
   sous-requête.
  </para>

  <para>
   Pour plus d'informations, voir <xref linkend="sql-values"
   endterm="sql-values-title"/>.
  </para>

 </sect1>


 <sect1 id="queries-with">
  <title>Requêtes <literal>WITH</literal></title>

  <indexterm zone="queries-with">
   <primary>WITH</primary>
   <secondary>dans SELECT</secondary>
  </indexterm>

  <indexterm>
   <primary>common table expression</primary>
   <see>WITH</see>
  </indexterm>

  <para>
   <literal>WITH</literal> fournit une façon d'écrire les sous-requêtes pour
   utilisation dans une requête <literal>SELECT</literal> plus étendue. Les
   sous-requêtes peuvent être considérées comme la déclaration d'une table
   temporaire n'existant que pour la requête. Une utilisation de cette
   fonctionnalité est de découper des requêtes complexes en parties plus simples.
   En voici un exemple&nbsp;:

<programlisting>WITH ventes_regionales AS (
        SELECT region, SUM(montant) AS ventes_totales
        FROM commandes
        GROUP BY region
     ), meilleures_regions AS (
        SELECT region
        FROM ventes_regionales
        WHERE ventes_totales &gt; (SELECT SUM(ventes_totales)/10 FROM ventes_regionales)
     )
SELECT region,
       produit,
       SUM(quantite) AS unites_produit,
       SUM(montant) AS ventes_produit
FROM commandes
WHERE region IN (SELECT region FROM meilleures_regions)
GROUP BY region, produit;</programlisting>

   qui affiche les totaux de ventes par produit dans seulement les régions
   ayant les meilleures ventes. 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
   façon.
  </para>

  <para>
   Le modificateur optionnel <literal>RECURSIVE</literal> fait passer
   <literal>WITH</literal> du statut de simple aide syntaxique à celui de
   quelque chose qu'il serait impossible d'accomplir avec du SQL standard.
   Grâce à <literal>RECURSIVE</literal>, une requête <literal>WITH</literal>
   peut utiliser sa propre sortie. Un exemple très simple se trouve dans cette
   requête, qui ajoute les nombres de 1 à 100&nbsp;:

<programlisting>WITH RECURSIVE t(n) AS (
    VALUES (1)
  UNION ALL
    SELECT n+1 FROM t WHERE n &lt; 100
)
SELECT sum(n) FROM t;</programlisting>

   La forme générale d'une requête <literal>WITH</literal> est toujours un
   <firstterm>terme non-recursif</firstterm>, puis <literal>UNION</literal> (ou
   <literal>UNION ALL</literal>), puis un <firstterm>terme récursif</firstterm>.
   Seul le terme récursif peut contenir une référence à la sortie propre de la
   requête. Une requête de ce genre est exécutée comme suit&nbsp;:
  </para>

  <procedure>
   <title>Évaluation de requête récursive</title>

   <step performance="required">
    <para>
     Évaluer le terme non récursif. Pour <literal>UNION</literal> (mais pas
     <literal>UNION ALL</literal>), supprimer les enregistrements en double.
     Inclure le reste dans le résultat de la requête récursive et le mettre
     aussi dans une table temporaire de travail (<firstterm>working table</firstterm>.)
    </para>
   </step>

   <step performance="required">
    <para>
     Tant que la table de travail n'est pas vide, répéter ces étapes&nbsp;:
    </para>
    <substeps>
     <step performance="required">
      <para>
       Évaluer le terme récursif, en substituant à la référence récursive
       le contenu courant de la table de travail.
       Pour <literal>UNION</literal> (mais pas <literal>UNION ALL</literal>),
       supprimer les doublons, ainsi que les enregistrements en doublon des
       enregistrements déjà obtenus. Inclure les enregistrements restants dans
       le résultat de la requête récursive, et les mettre aussi dans une table
       temporaire intermédiaire (<firstterm>intermediate table</firstterm>).
      </para>
     </step>

     <step performance="required">
      <para>
       Remplacer le contenu de la table de travail par celui de la table
       intermédiaire, puis supprimer la table intermédiaire.
      </para>
     </step>
    </substeps>
   </step>
  </procedure>

  <note>
   <para>
    Dans son appellation stricte, ce processus est une itération, pas une
    récursion, mais <literal>RECURSIVE</literal> est la terminologie choisie
    par le comité de standardisation de SQL.
   </para>
  </note>

  <para>
   Dans l'exemple précédent, la table de travail a un seul enregistrement à
   chaque étape, et il prend les valeurs de 1 à 100 en étapes successives.
   À la centième étape, il n'y a plus de sortie en raison de la clause
   <literal>WHERE</literal>, ce qui met fin à la requête.
  </para>

  <para>
   Les requêtes récursives sont utilisées généralement pour traiter des données
   hiérarchiques ou sous forme d'arbres. Cette requête est un exemple utile
   pour trouver toutes les sous-parties directes et indirectes d'un produit,
   si seule une table donne toutes les inclusions immédiates&nbsp;:

<programlisting>WITH RECURSIVE parties_incluses(sous_partie, partie, quantite) AS (
    SELECT sous_partie, partie, quantite FROM parties WHERE partie = 'notre_produit'
  UNION ALL
    SELECT p.sous_partie, p.partie, p.quantite
    FROM parties_incluses pr, parties p
    WHERE p.partie = pr.sous_partie
  )
SELECT sous_partie, SUM(quantite) as quantite_totale
FROM parties_incluses
GROUP BY sous_partie</programlisting>
  </para>

  <para>
   Quand on travaille avec des requêtes récursives, il est important d'être sûr
   que la partie récursive de la requête finira par ne retourner aucun enregistrement,
   au risque sinon de voir la requête boucler indéfiniment. Quelquefois, utiliser
   <literal>UNION</literal> à la place de <literal>UNION ALL</literal> peut
   résoudre le problème en supprimant les enregistrements qui doublonnent ceux déjà
   retournés. Toutefois, souvent, un cycle ne met pas en jeu des enregistrements de
   sortie qui sont totalement des doublons&nbsp;: il peut s'avérer nécessaire de
   vérifier juste un ou quelques champs, afin de s'assurer que le même point a déjà
   été atteint précédemment. La méthode standard pour gérer ces situations est de
   calculer un tableau de valeurs déjà visitées. Par exemple, observez la requête
   suivante, qui parcourt une table <structname>graphe</structname> en utilisant
   un champ <structfield>lien</structfield>&nbsp;:

<programlisting>
WITH RECURSIVE parcourt_graphe(id, lien, donnee, profondeur) AS (
        SELECT g.id, g.lien, g.donnee, 1
        FROM graphe g
      UNION ALL
        SELECT g.id, g.lien, g.donnee, sg.profondeur + 1
        FROM graphe g, parcourt_graphe sg
        WHERE g.id = sg.lien
)
SELECT * FROM parcourt_graphe;
</programlisting>

   Cette requête va boucler si la liaison <structfield>lien</structfield>
   contient des boucles. Parce que nous avons besoin de la sortie
   <quote>profondeur</quote>, simplement remplacer <literal>UNION ALL</literal>
   par <literal>UNION</literal> ne résoudra pas le problème.
   À la place, nous avons besoin d'identifier si nous avons atteint un enregistrement
   que nous avons déjà traité pendant notre parcours des liens. Nous ajoutons
   deux colonnes <structfield>chemin</structfield> et <structfield>boucle</structfield>
   à la requête&nbsp;:
<programlisting>
WITH RECURSIVE parcourt_graphe(id, lien, donnee, profondeur, chemin, boucle) AS (
        SELECT g.id, g.lien, g.donnee, 1,
          ARRAY[g.id],
          false
        FROM graphe g
      UNION ALL
        SELECT g.id, g.lien, g.donnee, sg.profondeur + 1,
          chemin || g.id,
          g.id = ANY(chemin)
        FROM graphe g, parcourt_graphe sg
        WHERE g.id = sg.lien AND NOT boucle
)
SELECT * FROM parcourt_graphe;
</programlisting>

   En plus de prévenir les boucles, cette valeur de tableau est souvent pratique
   en elle-même pour représenter le <quote>chemin</quote> pris pour atteindre
   chaque enregistrement.
  </para>

  <para>
   De façon plus générale, quand plus d'un champ a besoin d'être vérifié pour
   identifier une boucle, utilisez un tableau d'enregistrements. Par exemple,
   si nous avions besoin de comparer les champs <structfield>f1</structfield> et
   <structfield>f2</structfield>&nbsp;:

<programlisting>
WITH RECURSIVE parcourt_graphe(id, lien, donnee, profondeur, chemin, boucle) AS (
        SELECT g.id, g.lien, g.donnee, 1,
          ARRAY[ROW(g.f1, g.f2)],
          false
        FROM graphe g
      UNION ALL
        SELECT g.id, g.lien, g.donnee, sg.profondeur + 1,
          chemin || ROW(g.f1, g.f2),
          ROW(g.f1, g.f2) = ANY(path)
        FROM graphe g, parcourt_graphe sg
        WHERE g.id = sg.link AND NOT boucle
)
SELECT * FROM parcourt_graphe;
</programlisting>
  </para>

  <tip>
   <para>
    Omettez la syntaxe <literal>ROW()</literal> dans le cas courant où un seul
    champ a besoin d'être testé pour déterminer une boucle. Ceci permet, par
    l'utilisation d'un tableau simple plutôt que d'un tableau de type composite,
    de gagner en efficacité.
   </para>
  </tip>

  <tip>
   <para>
    L'algorithme d'évaluation récursive de requête produit sa sortie en ordre
    de parcours en largeur (algorithme <foreignphrase>breadth-first</foreignphrase>).
    Vous pouvez afficher les résultats en ordre de parcours en profondeur
    (<foreignphrase>depth-first</foreignphrase>) en faisant sur la requête
    externe un <literal>ORDER BY</literal> sur une colonne <quote>chemin</quote>
    construite de cette façon.
   </para>
  </tip>

  <para>
   Si vous n'êtes pas certain qu'une requête peut boucler, une astuce pratique
   pour la tester est d'utiliser <literal>LIMIT</literal> dans la requête parente.
   Par exemple, cette requête bouclerait indéfiniment sans un
   <literal>LIMIT</literal>&nbsp;:

<programlisting>
WITH RECURSIVE t(n) AS (
    SELECT 1
  UNION ALL
    SELECT n+1 FROM t
)
SELECT n FROM t LIMIT 100;
</programlisting>

   Ceci fonctionne parce que l'implémentation de <productname>PostgreSQL</productname>
   n'évalue que le nombre d'enregistrements de la requête <literal>WITH</literal>
   récupérés par la requête parente. L'utilisation de cette astuce en production
   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.
  </para>

  <para>
   Une propriété intéressante des requêtes <literal>WITH</literal> est qu'elles
   ne sont évaluées qu'une seule fois par exécution de la requête parente ou
   des requêtes <literal>WITH</literal> s&oelig;urs.
   Par conséquent, les calculs coûteux qui sont nécessaires à plusieurs endroits
   peuvent être placés dans une requête <literal>WITH</literal> pour éviter le
   travail redondant. Un autre intérêt peut être d'éviter l'exécution multiple
   d'une fonction ayant des effets de bord.
   Toutefois, le revers de la médaille est que l'optimiseur est moins capable
   d'extrapoler les restrictions de la requête parente vers une requête
   <literal>WITH</literal> que vers une sous-requête classique. La requête
   <literal>WITH</literal> sera généralement exécutée telle quelle, sans
   suppression d'enregistrements, que la requête parente devra supprimer ensuite.
   (Mais, comme mentionné précédemment, l'évaluation pourrait s'arrêter rapidement
   si la (les) référence(s) à la requête ne demande(nt) qu'un nombre limité
   d'enregistrements).
  </para>

 </sect1>

</chapter>