rules.xml

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

<chapter id="rules">
<title>Système de règles</title>

 <indexterm zone="rules">
  <primary>règle</primary>
 </indexterm>

<para>
     Ce chapitre discute du système de règles dans
     <productname>PostgreSQL</productname>. les systèmes de règles de
     production sont simples conceptuellement mais il existe de nombreux points
     subtils impliqués dans leur utilisation.
</para>

<para>
     Certains autres systèmes de bases de données définissent des règles actives
     pour la base de données, conservées habituellement en tant que procédures
     stockées et déclencheurs. Avec <productname>PostgreSQL</productname>, elles
     peuvent aussi être implémentées en utilisant des fonctions et des
     déclencheurs.
</para>

<para>
     Le système de règles (plus précisément, le système de règles de
     réécriture de requêtes) est totalement différent des procédures stockées et
     des déclencheurs. Il modifie les requêtes pour prendre en considération les
     règles puis passe la requête modifiée au planificateur de requêtes pour
     planification et exécution. Il est très puissant et peut être utilisé pour
     beaucoup de choses comme des procédures en langage de requêtes, des vues et
     des versions. Les fondations théoriques et la puissance de ce système de
     règles sont aussi discutées dans <xref linkend="ston90b"/> et <xref
     linkend="ong90"/>.
</para>

<sect1 id="querytree">
<title>Arbre de requêtes</title>

<indexterm zone="querytree">
 <primary>arbre de requêtes</primary>
</indexterm>

<para>
    Pour comprendre comment fonctionne le système de règles, il est nécessaire
    de comprendre quand il est appelé et quelles sont ses entrées et sorties.
</para>

<para>
    Le système de règles est situé entre l'analyseur et le planificateur. Il
    prend la sortie de l'analyseur, un arbre de requête et les règles de
    réécriture définies par l'utilisateur qui sont aussi des arbres de requêtes
    avec quelques informations supplémentaires, et crée zéro ou plusieurs arbres
    de requêtes comme résultat. Donc, son entrée et sortie sont toujours des
    éléments que l'analyseur lui-même pourrait avoir produit et, du coup, tout
    ce qu'il voit est représentable basiquement comme une instruction
    <acronym>SQL</acronym>.
</para>

<para>
    Maintenant, qu'est-ce qu'un arbre de requêtes&nbsp;? C'est une
    représentation interne d'une instruction <acronym>SQL</acronym> où les
    parties qui le forment sont stockées séparément. Ces arbres de requêtes sont
    affichables dans le journal de traces du serveur si vous avez configuré les
    paramètres <varname>debug_print_parse</varname>,
    <varname>debug_print_rewritten</varname>, ou
    <varname>debug_print_plan</varname>. les actions de règles sont aussi
    enregistrées comme arbres de requêtes dans le catalogue système
    <structname>pg_rewrite</structname>. elles ne sont pas formatées comme la
    sortie de traces mais elles contiennent exactement la même information.
</para>

<para>
    Lire un arbre de requête brut requiert un peu d'expérience. Mais comme les
    représentations <acronym>SQL</acronym> des arbres de requêtes sont
    suffisantes pour comprendre le système de règles, ce chapitre ne
    vous apprendra pas à les lire.
</para>

<para>
    Lors de la lecture des représentations <acronym>SQL</acronym> des arbres de
    requêtes dans ce chapitre, il est nécessaire d'être capable d'identifier les
    morceaux cassés de l'instruction lorsqu'ils sont dans la structure de l'arbre
    de requête. Les parties d'un arbre de requêtes sont

<variablelist>
    <varlistentry>
    <term>
        le type de commande
    </term>
    <listitem>
    <para>
        C'est une simple valeur indiquant quelle commande
        (<command>select</command>, <command>insert</command>,
        <command>update</command>, <command>delete</command>)
        l'arbre de requêtes produira.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        la table d'échelle
    </term>
    <listitem>
      <indexterm><primary>table d'échelle</primary></indexterm>
    <para>
        La table d'échelle est une liste des relations utilisées dans la
        requête. Dans une instruction <command>select</command>, ce sont les
        relations données après le mot clé <literal>from</literal>.
    </para>

    <para>
        Chaque entrée de la table d'échelle identifie une table ou une vue et
        indique par quel nom elle est désignée dans les autres parties de la
        requête. Dans l'arbre de requêtes, les entrées de la table d'échelle
        sont référencées par des numéros plutôt que par des noms. Il
        importe donc peu, ici, de savoir s'il y a des noms dupliqués comme cela
        peut être le cas avec une instruction <acronym>SQL</acronym>. Cela peut
        arriver après l'assemblage des tables d'échelle des règles.
        Les exemples de ce chapitre ne sont pas confrontés à cette situation.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        la relation résultat
    </term>
    <listitem>
    <para>
        C'est un index dans la table d'échelle qui identifie la relation où
        iront les résultats de la requête.
    </para>

    <para>
        Les requêtes <command>select</command> n'ont normalement pas de
        relation résultat. Le cas spécial d'un <command>select into</command>
        est pratiquement identique à un <command>create table</command> suivi
        par un <literal>insert ... select</literal> et n'est pas discuté
        séparément ici.
    </para>

    <para>
        Pour les commandes <command>insert</command>, <command>update</command>
	et <command>delete</command>, la relation de résultat est la table (ou
        vue&nbsp;!) où les changements prennent effet.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        la liste cible
    </term>
    <listitem>
    <indexterm><primary>liste cible</primary></indexterm>
    <para>
        La liste cible est une liste d'expressions définissant le résultat
        d'une requête. Dans le cas d'un <command>select</command>, ces
        expressions sont celles qui construisent la sortie finale de la requête.
        Ils correspondent aux expressions entre les mots clés
        <command>select</command> et <command>from</command>
        (<literal>*</literal> est seulement une abréviation pour tous les noms
        de colonnes d'une relation. Il est étendu par l'analyseur en colonnes
        individuelles, pour que le système de règles ne le voit jamais).
    </para>

    <para>
        Les commandes <command>delete</command> n'ont pas besoin d'une liste de
        colonnes car elles ne produisent aucun résultat. En fait, le
        planificateur ajoutera une entrée spéciale <acronym>ctid</acronym> pour aller
        jusqu'à la liste de cibles mais c'est après le système de règles&nbsp;;
        pour le système de règles, ce sera discuté après&nbsp;; pour le système
        de règles, la liste de cibles est vide.
    </para>

    <para>
        Pour les commandes <command>insert</command>, la liste cible décrit les
        nouvelles lignes devant aller dans la relation résultat. Elle consiste
        en des expressions de la clause <literal>values</literal> ou en celles de la
        clause <command>select</command> dans <literal>insert ...
        SELECT</literal>. la première étape du processus de réécriture ajoute
        les entrées de la liste cible pour les colonnes n'ont affectées par la
        commande originale mais ayant des valeurs par défaut. Toute colonne
        restante (avec soit une valeur donnée soit une valeur par défaut) sera
        remplie par le planificateur avec une expression NULL constante.
    </para>

    <para>
        Pour les commandes <command>update</command>, la liste cible décrit les
        nouvelles lignes remplaçant les anciennes. Dans le système des règles,
        elle contient seulement les expressions de la partie <literal>set
        colonne = expression</literal> de la commande. le planificateur gèrera
        les colonnes manquantes en insérant des expressions qui copient les
        valeurs provenant de l'ancienne ligne dans la nouvelle. et elle ajoutera
        l'ancienne entrée <acronym>ctid</acronym> dans la nouvelle ligne comme pour le
        <command>delete</command>.
    </para>

    <para>
        Chaque entrée de la liste cible contient une expression qui peut être
        une valeur constante, une variable pointant vers une colonne d'une des
        relations de la table d'échelle, un paramètre ou un arbre d'expressions
        réalisé à partir d'appels de fonctions, de constantes, de variables,
        d'opérateurs, etc.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        la qualification
    </term>
    <listitem>
    <para>
        La qualification de la requête est une expression ressemblant à une de
        celles contenues dans les entrées de la liste cible. La valeur résultant
        de cette expression est un booléen indiquant si l'opération
        (<command>insert</command>, <command>update</command>,
        <command>delete</command> ou <command>select</command>) pour la ligne de
        résultat final devrait être exécutée ou non. Elle correspond à la clause
        <literal>where</literal> d'une instruction <acronym>SQL</acronym>.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        l'arbre de jointure
    </term>
    <listitem>
    <para>
        L'arbre de jointure de la requête affiche la structure de la clause
        <literal>from</literal>. pour une simple requête comme <literal>select ... from
        a, b, c</literal>, l'arbre de jointure est une simple liste d'éléments
        de <literal>from</literal> parce que nous sommes autorisés à les joindre dans
        tout ordre. Mais quand des expressions <literal>join</literal>, et plus
        particulièrement les jointures externes, sont utilisées, nous devons les
        joindre dans l'ordre affiché par les jointures. Dans ce cas, l'arbre de
        jointure affiche la structure des expressions <literal>join</literal>. les
        restrictions associées avec ces clauses <literal>join</literal> particulières
        (à partir d'expressions <literal>on</literal> ou <literal>using</literal>) sont
        enregistrées comme des expressions de qualification attachées aux
n&oelig;uds
        de l'arbre de jointure. Il s'avère agréable d'enregistrer l'expression
        de haut niveau <literal>where</literal> comme une qualification attachée à
        l'élément de l'arbre de jointure de haut niveau. Donc, réellement,
        l'arbre de jointure représente à la fois les clauses <literal>from</literal> et
        <literal>where</literal> d'un <command>select</command>.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        le reste
    </term>
    <listitem>
    <para>
        Les autres parties de l'arbre de requête comme la clause <literal>order
        BY</literal> n'ont pas d'intérêt ici. le système de règles substitue quelques
        entrées lors de l'application des règles mais ceci n'a pas grand chose à
        voir avec les fondamentaux du système de règles.
    </para>
    </listitem>
    </varlistentry>

</variablelist>
</para>
</sect1>

<sect1 id="rules-views">
<title>Vues et système de règles</title>

<indexterm zone="rules-views">
 <primary>règle</primary>
 <secondary>et vues</secondary>
</indexterm>

<indexterm zone="rules-views">
 <primary>vue</primary>
 <secondary>implémentation par les règles</secondary>
</indexterm>

<para>
    Avec <productname>PostgreSQL</productname>, les vues sont implémentées en
    utilisant le système de règles. En fait, il n'y a essentiellement pas de
    différences entre&nbsp;

<programlisting>CREATE VIEW ma_vue AS SELECT * FROM ma_table;
</programlisting>
    
    et ces deux commandes&nbsp;:

<programlisting>CREATE TABLE ma_vue (<replaceable>liste de colonnes identique à celle de ma_table</replaceable>);
CREATE RULE "_RETURN" AS ON SELECT TO ma_vue DO INSTEAD
    SELECT * FROM ma_table;
</programlisting>
    
    parce que c'est exactement ce que fait la commande <command>create
    VIEW</command> en interne. Cela présente quelques effets de bord. L'un d'entre eux
    est que l'information sur une vue dans les catalogues système
    <productname>PostgreSQL</productname> est exactement la même que celle
    d'une table. Donc, pour l'analyseur, il n'y a aucune différence entre une
    table et une vue. Elles représentent la même chose&nbsp;: des relations.
</para>

<sect2 id="rules-select">
<title>Fonctionnement des règles <command>select</command></title>

<indexterm zone="rules-select">
 <primary>règle</primary>
 <secondary sortas="select">pour select</secondary>
</indexterm>

<para>
    Les règles <literal>on select</literal> sont appliquées à toutes les requêtes comme
    la dernière étape, même si la commande donnée est un
    <command>insert</command>, <command>update</command> ou
    <command>delete</command>. et ils ont des sémantiques différentes à partir
    des règles sur les autres types de commandes dans le fait qu'elles modifient
    l'arbre de requêtes en place au lieu d'en créer un nouveau. Donc, les règles
    <command>select</command> sont décrites avant.
</para>

<para>
    Actuellement, il n'existe qu'une action dans une règle <literal>on
    SELECT</literal> et elle doit être une action <command>select</command>
    inconditionnelle qui est <literal>instead</literal>. cette restriction était
    requise pour rendre les règles assez sûres pour les ouvrir aux utilisateurs
    ordinaires et cela restreint les règles <literal>on select</literal> à agir comme
    des vues.
</para>

<para>
    Pour ce chapitre, les exemples sont deux vues jointes réalisant quelques
    calculs et quelques vues supplémentaires les utilisant à leur tour. Une
    des deux premières vues est personnalisée plus tard en ajoutant des règles
    pour des opérations <command>insert</command>, <command>update</command> et
    <command>delete</command> de façon à ce que le résultat final sera une vue
    qui se comporte comme une vraie table avec quelques fonctionnalités
    magiques. Il n'existe pas un tel exemple pour commencer et ceci rend les
    choses plus difficiles à obtenir. Mais il est mieux d'avoir un exemple
    couvrant tous les points discutés étape par étape plutôt que plusieurs
    exemples, rendant la compréhension plus difficile.
</para>

<para>
    Pour cet exemple, nous avons besoin d'une petite fonction
    <literal>min</literal> renvoyant la valeur la plus basse entre deux entiers.
    Nous la créons ainsi&nbsp;:

<programlisting>CREATE FUNCTION min(integer, integer) RETURNS integer AS $$
    SELECT CASE WHEN $1 &lt; $2 THEN $1 ELSE $2 END
$$' LANGUAGE SQL STRICT;
</programlisting>
</para>

<para>
    Les tables réelles dont nous avons besoin dans les deux
    premières descriptions du système de règles sont les suivantes&nbsp;:

<programlisting>CREATE TABLE donnees_chaussure (
    nom_chaussure         text,     -- clé primaire
    dispo_chaussure       integer,  -- nombre de pairs disponibles
    couleur_chaussure     text,     -- couleur de lacet préférée
    long_min_chaussure    real,     -- longueur minimum du lacet
    long_max_chaussure    real,     -- longueur maximum du lacet
    unite_long_chaussure  text      -- unité de longueur
);

CREATE TABLE donnees_lacet (
    nom_lacet             text,     -- clé primaire
    dispo_lacet           integer,  -- nombre de pairs disponibles
    couleur_lacet         text,     -- couleur du lacet
    longueur_lacet        real,     -- longueur du lacet
    unite_lacet           text      -- unité de longueur
);

CREATE TABLE unite (
    nom_unite             text,     -- clé primaire
    facteur_unite         real      -- facteur pour le transformer en cm
);
</programlisting>

    Comme vous pouvez le constater, elles représentent les données d'un magasin
    de chaussures.
</para>

<para>
    Les vues sont créées avec&nbsp;:

<programlisting>CREATE VIEW chaussure AS
    SELECT sh.nom_chaussure,
           sh.dispo_chaussure,
           sh.couleur_chaussure,
           sh.long_min_chaussure,
           sh.long_min_chaussure * un.facteur_unite AS long_min_chaussure_cm,
           sh.long_max_chaussure,
           sh.long_max_chaussure * un.facteur_unite AS long_max_chaussure_cm,
           sh.unite_long_chaussure
      FROM donnees_chaussure sh, unite un
     WHERE sh.unite_long_chaussure = un.nom_unite;

CREATE VIEW lacet AS
    SELECT s.nom_lacet,
           s.dispo_lacet,
           s.couleur_lacet,
           s.longueur_lacet,
           s.unite_lacet,
           s.longueur_lacet * u.facteur_unite AS longueur_lacet_cm
      FROM donnees_lacet s, unite u
     WHERE s.unite_lacet = u.nom_unite;

CREATE VIEW chaussure_prete AS
    SELECT rsh.nom_chaussure,
           rsh.dispo_chaussure,
           rsl.nom_lacet,
           rsl.dispo_lacet,
           min(rsh.dispo, rsl.dispo_lacet) AS total_avail
      FROM chaussure rsh, lacet rsl
     WHERE rsl.couleur_lacet = rsh.couleur
       AND rsl.longueur_lacet_cm &gt;= rsh.long_min_chaussure_cm
       AND rsl.longueur_lacet_cm &lt;= rsh.long_max_chaussure_cm;
</programlisting>

    La commande <command>create view</command> pour la vue
    <literal>lacet</literal> (qui est la plus simple que nous avons) écrira
    une relation <literal>lacet</literal> et une entrée dans
    <structname>pg_rewrite</structname> indiquant la présence d'une règle de
    réécriture devant être appliquée à chaque fois que la relation
    <literal>lacet</literal> est référencée dans une table de la requête.
    La règle n'a aucune qualification de règle (discuté plus tard, avec les
    règles autres que <command>select</command> car les règles <command>select</command> ne
    le sont pas encore) et qu'il s'agit de <literal>instead</literal>. notez que les
    qualifications de règles ne sont pas identiques aux qualifications de
    requêtes. L'action de notre règle a une qualification de requête. L'action
    de la règle a un arbre de requête qui est une copie de l'instruction
    <command>select</command> dans la commande de création de la vue.
</para>

    <note>
    <para>
    Les deux entrées supplémentaires de la table d'échelle pour <literal>new</literal>
    et <literal>old</literal> (nommées <literal>*new*</literal> et <literal>*old*</literal> pour des
    raisons historiques dans l'arbre de requête affiché) que vous pouvez voir
    dans l'entrée de <structname>pg_rewrite</structname> ne sont d'aucun intérêt
    pour les règles <command>select</command>.
    </para>
    </note>

<para>
    Maintenant, nous remplissons <literal>unit</literal>,
    <literal>donnees_chaussure</literal> et <literal>donnees_lacet</literal>,
    puis nous lançons une requête simple sur une vue&nbsp;:

<programlisting>INSERT INTO unite VALUES ('cm', 1.0);
INSERT INTO unite VALUES ('m', 100.0);
INSERT INTO unite VALUES ('inch', 2.54);

INSERT INTO donnees_chaussure VALUES ('sh1', 2, 'black', 70.0, 90.0, 'cm');
INSERT INTO donnees_chaussure VALUES ('sh2', 0, 'black', 30.0, 40.0, 'inch');
INSERT INTO donnees_chaussure VALUES ('sh3', 4, 'brown', 50.0, 65.0, 'cm');
INSERT INTO donnees_chaussure VALUES ('sh4', 3, 'brown', 40.0, 50.0, 'inch');

INSERT INTO donnees_lacet VALUES ('sl1', 5, 'black', 80.0, 'cm');
INSERT INTO donnees_lacet VALUES ('sl2', 6, 'black', 100.0, 'cm');
INSERT INTO donnees_lacet VALUES ('sl3', 0, 'black', 35.0 , 'inch');
INSERT INTO donnees_lacet VALUES ('sl4', 8, 'black', 40.0 , 'inch');
INSERT INTO donnees_lacet VALUES ('sl5', 4, 'brown', 1.0 , 'm');
INSERT INTO donnees_lacet VALUES ('sl6', 0, 'brown', 0.9 , 'm');
INSERT INTO donnees_lacet VALUES ('sl7', 7, 'brown', 60 , 'cm');
INSERT INTO donnees_lacet VALUES ('sl8', 1, 'brown', 40 , 'inch');

SELECT * FROM lacet;

 nom_lacet   | dispo_lacet | couleur_lacet | longueur_lacet | unite_lacet | longueur_lacet_cm
-------------+-------------+---------------+----------------+-------------+------------------
 sl1         |           5 | black         |             80 | cm          |               80
 sl2         |           6 | black         |            100 | cm          |              100
 sl7         |           7 | brown         |             60 | cm          |               60
 sl3         |           0 | black         |             35 | inch        |             88.9
 sl4         |           8 | black         |             40 | inch        |            101.6
 sl8         |           1 | brown         |             40 | inch        |            101.6
 sl5         |           4 | brown         |              1 | m           |              100
 sl6         |           0 | brown         |            0.9 | m           |               90
(8 rows)
</programlisting>
   </para>

   <para>
    C'est la requête <command>select</command> la plus simple que vous pouvez
    lancer sur nos vues, donc nous prenons cette opportunité d'expliquer les
    bases des règles de vues. <literal>select * from lacet</literal> a été
    interprété par l'analyseur et a produit l'arbre de requête&nbsp;:

<programlisting>SELECT lacet.nom_lacet, lacet.dispo_lacet,
       lacet.couleur_lacet, lacet.longueur_lacet,
       lacet.unite_lacet, lacet.longueur_lacet_cm
  FROM lacet lacet;
</programlisting>

    et ceci est transmis au système de règles. Ce système traverse la table
    d'échelle et vérifie s'il existe des règles pour chaque relation. Lors du
    traitement d'une entrée de la table d'échelle pour
    <literal>lacet</literal> (la seule jusqu'à maintenant), il trouve la
    règle <literal>_return</literal> avec l'arbre de requête&nbsp;:

<programlisting>SELECT s.nom_lacet, s.dispo_lacet,
       s.couleur_lacet, s.longueur_lacet, s.unite_lacet,
       s.longueur_lacet * u.facteur_unite AS longueur_lacet_cm
  FROM lacet *OLD*, lacet *NEW*,
       donnees_lacet s, unit u
 WHERE s.unite_lacet = u.nom_unite;
</programlisting>
</para>

<para>
    Pour étendre la vue, la réécriture crée simplement une entrée de la table
d'échelle de sous-requête contenant l'arbre de requête de l'action de la règle
et substitue cette entrée avec l'original référencé dans la vue. L'arbre
d'échelle résultant de la réécriture est pratiquement identique à celui que
vous avez saisi&nbsp;:

<programlisting>SELECT lacet.nom_lacet, lacet.dispo_lacet,
       lacet.couleur_lacet, lacet.longueur_lacet,
       lacet.unite_lacet, lacet.longueur_lacet_cm
  FROM (SELECT s.nom_lacet,
               s.dispo_lacet,
               s.couleur_lacet,
               s.longueur_lacet,
               s.unite_lacet,
               s.longueur_lacet * u.facteur_unite AS longueur_lacet_cm
          FROM donnees_lacet s, unit u
         WHERE s.unite_lacet = u.nom_unite) lacet;
</programlisting>

     Néanmoins, il y a une différence&nbsp;: la table d'échelle de la
     sous-requête a deux entrées supplémentaires, <literal>lacet *old*</literal> et
     <literal>lacet *new*</literal>. ces entrées ne participent pas directement dans
     la requête car elles ne sont pas référencées par l'arbre de jointure de la
     sous-requête ou par la liste cible. La réécriture les utilise pour
     enregistrer l'information de vérification des droits d'accès qui étaient
     présents à l'origine dans l'entrée de table d'échelle référencée par la
     vue. De cette façon, l'exécution vérifiera toujours que l'utilisateur a les
     bons droits pour accéder à la vue même s'il n'y a pas d'utilisation directe
     de la vue dans la requête réécrite.
</para>

<para>
    C'était la première règle appliquée. Le système de règles continuera de
    vérifier les entrées restantes de la table d'échelle dans la requête
    principale (dans cet exemple, il n'en existe pas plus), et il vérifiera
    récursivement les entrées de la table d'échelle dans la sous-requête ajoutée
    pour voir si une d'elle référence les vues. (Mais il n'étendra ni
    <literal>*old*</literal> ni <literal>*new*</literal> &mdash; sinon nous aurions une récursion
    infinie&nbsp;!) Dans cet exemple, il n'existe pas de règles de réécriture
    pour <literal>donnees_lacet</literal> ou <literal>unit</literal>, donc la réécriture est
    terminée et ce qui est ci-dessus est le résultat final donné au
    planificateur.
</para>

<para>
    Maintenant, nous voulons écrire une requête qui trouve les chaussures
    en magasin dont nous avons les lacets correspondants
    (couleur et longueur) et pour lesquels le nombre total de pairs
    correspondants exactement est supérieur ou égal à deux.

<programlisting>SELECT * FROM chaussure_prete WHERE total_avail &gt;= 2;

 nom_chaussure | dispo | nom_lacet | dispo_lacet | total_avail
---------------+-------+-----------+-------------+-------------
 sh1           |     2 | sl1       |           5 |           2
 sh3           |     4 | sl7       |           7 |           4
(2 rows)
</programlisting>
</para>

<para>
    Cette fois, la sortie de l'analyseur est l'arbre de requête&nbsp;:

<programlisting>SELECT chaussure_prete.nom_chaussure, chaussure_prete.dispo,
       chaussure_prete.nom_lacet, chaussure_prete.dispo_lacet,
       chaussure_prete.total_avail
  FROM chaussure_prete chaussure_prete
 WHERE chaussure_prete.total_avail &gt;= 2;
</programlisting>

    La première règle appliquée sera celle de la vue
    <literal>chaussure_prete</literal> et cela résultera en cet arbre de
    requête&nbsp;:

<programlisting>SELECT chaussure_prete.nom_chaussure, chaussure_prete.dispo,
       chaussure_prete.nom_lacet, chaussure_prete.dispo_lacet,
       chaussure_prete.total_avail
  FROM (SELECT rsh.nom_chaussure,
               rsh.dispo,
               rsl.nom_lacet,
               rsl.dispo_lacet,
               min(rsh.dispo, rsl.dispo_lacet) AS total_avail
          FROM chaussure rsh, lacet rsl
         WHERE rsl.couleur_lacet = rsh.couleur
          AND rsl.longueur_lacet_cm &gt;= rsh.long_min_chaussure_cm
          AND rsl.longueur_lacet_cm &lt;= rsh.long_max_chaussure_cm) chaussure_prete
 WHERE chaussure_prete.total_avail &gt;= 2;
</programlisting>

    De façon similaire, les règles pour <literal>chaussure</literal> et
    <literal>lacet</literal> sont substituées dans la table d'échelle de 
    la sous-requête, amenant à l'arbre de requête final à trois niveaux&nbsp;:

<programlisting>SELECT chaussure_prete.nom_chaussure, chaussure_prete.dispo,
       chaussure_prete.nom_lacet, chaussure_prete.dispo_lacet,
       chaussure_prete.total_avail
  FROM (SELECT rsh.nom_chaussure,
               rsh.dispo,
               rsl.nom_lacet,
               rsl.dispo_lacet,
               min(rsh.dispo, rsl.dispo_lacet) AS total_avail
          FROM (SELECT sh.nom_chaussure,
                       sh.dispo,
                       sh.couleur,
                       sh.long_min_chaussure,
                       sh.long_min_chaussure * un.facteur_unite AS long_min_chaussure_cm,
                       sh.long_max_chaussure,
                       sh.long_max_chaussure * un.facteur_unite AS long_max_chaussure_cm,
                       sh.unite_long_chaussure
                  FROM donnees_chaussure sh, unit un
                 WHERE sh.unite_long_chaussure = un.nom_unite) rsh,
               (SELECT s.nom_lacet,
                       s.dispo_lacet,
                       s.couleur_lacet,
                       s.longueur_lacet,
                       s.unite_lacet,
                       s.longueur_lacet * u.facteur_unite AS longueur_lacet_cm
                  FROM donnees_lacet s, unit u
                 WHERE s.unite_lacet = u.nom_unite) rsl
         WHERE rsl.couleur_lacet = rsh.couleur
           AND rsl.longueur_lacet_cm &gt;= rsh.long_min_chaussure_cm
           AND rsl.longueur_lacet_cm &lt;= rsh.long_max_chaussure_cm) chaussure_prete
 WHERE chaussure_prete.total_avail &gt; 2;
</programlisting>
   </para>

   <para>
    Il s'avère que le planificateur réduira cet arbre en un arbre de requête
    à deux niveaux&nbsp;: les commandes <command>select</command> du bas seront
    <quote>remontées</quote> dans le <command>select</command> du milieu car il
    n'est pas nécessaire de les traiter séparément. Mais le
    <command>select</command> du milieu restera séparé du haut car il contient
    des fonctions d'agrégat. Si nous les avions monté, cela aurait modifié le
    comportement du <command>select</command> de haut niveau, ce qui n'est pas
    ce que nous voulons. Néanmoins, réduire l'arbre de requête est une
    optimisation qui ne concerne pas le système de réécriture.
   </para>
</sect2>

<sect2>
<title>Règles de vue dans des instructions autres que <command>select</command></title>

<para>
    Deux détails de l'arbre de requête n'ont pas été abordés dans la
    description des règles de vue ci-dessus. Ce sont le type de commande et le
    relation résultante. En fait, les règles de vue n'ont pas besoin de cette
    information.
</para>

<para>
    Il existe seulement quelques différences entre un arbre de requête pour un
    <command>select</command> et un pour une autre commande. de façon évidente,
ils ont un type de commande différent et pour une commande autre qu'
un <command>select</command>, la relation résultante pointe vers l'entrée de
table d'échelle où le résultat devrait arriver. Tout le reste est absolument
identique. Donc, avec deux tables <literal>t1</literal> et <literal>t2</literal> avec les
colonnes <literal>a</literal> et <literal>b</literal>, les arbres de requêtes pour les
deux commandes&nbsp;:

<programlisting>SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;

UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;
</programlisting>

    sont pratiquement identiques. En particulier&nbsp;:

    <itemizedlist>
        <listitem>
	<para>
	    Les tables d'échelle contiennent des entrées pour les tables
	    <literal>t1</literal> et <literal>t2</literal>.
	</para>
        </listitem>

        <listitem>
	<para>
	    Les listes cibles contiennent une variable pointant vers la colonne
	    <literal>b</literal> de l'entrée de la table d'échelle pour la table
	    <literal>t2</literal>.
	</para>
        </listitem>

        <listitem>
	<para>
	    Les expressions de qualification comparent les colonnes
	    <literal>a</literal> des deux entrées de table d'échelle pour une égalité.
	</para>
        </listitem>

        <listitem>
	<para>
	    Les arbres de jointure affichent une jointure simple entre
	    <literal>t1</literal> et <literal>t2</literal>.
	</para>
        </listitem>
    </itemizedlist>
   </para>

   <para>
    La conséquence est que les deux arbres de requête résultent en des plans
    d'exécution similaires&nbsp;: ce sont tous les deux des jointures sur les
    deux tables. Pour l'<command>update</command>, les colonnes manquantes 
    de <literal>t1</literal> sont ajoutées à la liste cible par le planificateur et
    l'arbre de requête final sera lu de cette façon&nbsp;:

<programlisting>UPDATE t1 SET a = t1.a, b = t2.b FROM t2 WHERE t1.a = t2.a;
</programlisting>

    et, du coup, l'exécuteur lancé sur la jointure produira exactement le même
    résultat qu'un&nbsp;:

<programlisting>SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
</programlisting>
    
    le ferait. Mais il y a un petit problème avec
    <command>update</command>&nbsp;: l'exécuteur ne fait pas attention au but du
    résultat de la jointure. Il produit simplement un ensemble de lignes
    composant le résultat. La différence entre une commande
    <command>select</command> et une commande <command>update</command> est
    gérée par celui qui a appelé l'exécuteur. L'appelant sait toujours (en
    regardant dans l'arbre de requêtes) qu'il s'agit d'un
    <command>update</command>, et il sait que le résultat ira dans la table
    <literal>t1</literal>. mais quelles lignes disponibles maintenant seront remplacées
    par les nouvelles lignes&nbsp;?
</para>

<para>
    Pour résoudre ce problème, une autre entrée est ajoutée dans la liste
    cible de l'<command>update</command> (et aussi dans les instructions
    <command>delete</command>)&nbsp;: l'identifiant actuel du tuple
    (<acronym>ctid</acronym>, acronyme de <foreignphrase>current tuple
    ID</foreignphrase>).<indexterm><primary>ctid</primary></indexterm> cette colonne système
    contient le numéro de bloc du fichier et la position dans le bloc pour
    cette ligne. Connaissant la table, le <acronym>ctid</acronym> peut être utilisé
    pour récupérer la ligne originale de <literal>t1</literal> à mettre à jour. après
    avoir ajouté le <acronym>ctid</acronym> dans la liste cible, la requête ressemble à
    ceci&nbsp;:

<programlisting>SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
</programlisting>
    
    Maintenant, un autre détail de <productname>PostgreSQL</productname> entre
    en jeu. Les anciennes lignes de la table ne sont pas surchargées et cela
    explique pourquoi <command>rollback</command> est rapide. avec un
    <command>update</command>, la nouvelle ligne résultat est insérée dans la
    table (après avoir enlevé le <acronym>ctid</acronym>) et, dans le nouvel en-tête de
    ligne de l'ancienne ligne, vers où pointe le <acronym>ctid</acronym>, les entrées
    <literal>cmax</literal> et <literal>xmax</literal> sont configurées par le compteur de
    commande actuel et par l'identifiant de transaction actuel. Du coup,
    l'ancienne ligne est cachée et, après validation de la transaction, le
    nettoyeur (vacuum) peut réellement la supprimer.
</para>

<para>
    Connaissant tout ceci, nous pouvons simplement appliquer les règles de vues
    de la même façon que toute autre commande. Il n'y a pas de différence.
</para>
</sect2>

<sect2>
<title>Puissance des vues dans <productname>PostgreSQL</productname></title>

<para>
    L'exemple ci-dessus démontre l'incorporation des définitions de 
    vues par le système de règles dans l'arbre de requête original. Dans le
    deuxième exemple, un simple <command>select</command> d'une vue a créé un
    arbre de requête final qui est une jointure de quatre tables
    (<literal>unit</literal> a été utilisé deux fois avec des noms différents).
</para>

<para>
    Le bénéfice de l'implémentation des vues avec le système de règles est que
    le planificateur a toute l'information sur les tables à parcourir et sur
    les relations entre ces tables et les qualifications restrictives à partir
    des vues et les qualifications à partir de la requête originale dans un
    seule arbre de requête. Et c'est toujours la situation quand la requête
    originale est déjà une jointure sur des vues. Le planificateur doit décider
    du meilleur chemin pour exécuter la requête et plus le planificateur a
    d'informations, meilleure sera la décision. Le système de règles implémenté
    dans <productname>PostgreSQL</productname> s'en assure, c'est toute
    l'information disponible sur la requête à ce moment.
</para>
</sect2>

<sect2 id="rules-views-update">
<title>Mise à jour d'une vue</title>

<para>
    Qu'arrive-t'il si une vue est nommée comme la relation cible d'un
    <command>insert</command>, <command>update</command> ou
    <command>delete</command>&nbsp;? après avoir réalisées les substitutions
    décrites ci-dessus, nous aurons un arbre de requête dans lequel la relation
    résultante pointe vers une entrée de la table d'échelle de la sous-requête.
    Ceci ne fonctionnera pas car la réécriture renvoie une erreur si elle
    aperçoit qu'elle a produit une telle chose.
</para>

<para>
    Pour modifier ceci, nous pouvons définir des règles modifiant le
    comportement de ce type de commandes. C'est donc le thème de la prochaine
    section.
</para>
</sect2>

</sect1>

<sect1 id="rules-update">
<title>Règles sur <command>insert</command>, <command>update</command> et
<command>delete</command></title>

<indexterm zone="rules-update">
 <primary>règle</primary>
 <secondary sortas="insert">pour insert</secondary>
</indexterm>

<indexterm zone="rules-update">
 <primary>règle</primary>
 <secondary sortas="update">pour update</secondary>
</indexterm>

<indexterm zone="rules-update">
 <primary>règle</primary>
 <secondary sortas="delete">pour delete</secondary>
</indexterm>

<para>
    Les règles définies sur <command>insert</command>, <command>update</command>
    et <command>delete</command> sont significativement différentes des règles de
    vue décrites dans la section précédente. Tout d'abord, leur commande
    <command>create rule</command> permet plus de choses&nbsp;:

    <itemizedlist>
        <listitem>
	<para>
	    Elles peuvent n'avoir aucune action.
	</para>
	</listitem>

        <listitem>
	<para>
	    Elles peuvent avoir plusieurs actions.
	</para>
	</listitem>

        <listitem>
	<para>
	    Elles peuvent être de type <literal>instead</literal> ou <literal>also</literal>
	    (valeur par défaut).
	</para>
	</listitem>

        <listitem>
	<para>
	    Les pseudo relations <literal>new</literal> et <literal>old</literal> deviennent
	    utiles.
	</para>
	</listitem>

        <listitem>
	<para>
	    Elles peuvent avoir des qualifications de règles.
	</para>
	</listitem>
    </itemizedlist>

    Ensuite, elles ne modifient pas l'arbre de requête en place. À la place,
    elles créent de nouveaux arbres de requêtes et peuvent abandonner
    l'original.
</para>

<sect2>
<title>Fonctionnement des règles de mise à jour</title>

<para>
    Gardez en tête la syntaxe&nbsp;:

<programlisting>CREATE [ OR REPLACE ] RULE <replaceable class="parameter">nom</replaceable> as on <replaceable class="parameter">evenement</replaceable>
    TO <replaceable class="parameter">table</replaceable> [ where <replaceable class="parameter">condition</replaceable> ]
    DO [ ALSO | INSTEAD ] { NOTHING | <replaceable class="parameter">commande</replaceable> | ( <replaceable class="parameter">commande</replaceable> ; <replaceable class="parameter">commande</replaceable> ... ) }
</programlisting>

    Dans la suite, <firstterm>règles de mise à jour</firstterm> signifie les règles qui
    sont définies sur <command>insert</command>, <command>update</command> ou
    <command>delete</command>.
</para>

<para>
    Les règles de mise à jour sont appliquées par le système de règles lorsque
    la relation résultante et le type de commande d'un arbre de requête sont
    égaux pour l'objet et l'événement donné dans la commande <command>create
    RULE</command>. pour les règles de mise à jour, le système de règles crée
    une liste d'arbres de requêtes. Initialement, la liste d'arbres de requêtes
    est vide. Il peut y avoir aucune (mot clé <literal>nothing</literal>), une ou
    plusieurs actions. Pour simplifier, nous verrons une règle avec une action.
    Cette règle peut avoir une  qualification et peut être de type
    <literal>instead</literal> ou <literal>also</literal> (valeur par défaut).
</para>

<para>
    Qu'est-ce qu'une qualification de règle&nbsp;? C'est une restriction
    indiquant le moment où doivent être réalisés les actions de la règle. Cette
    qualification peut seulement référencer les pseudo relations <literal>new</literal>
    et/ou <literal>old</literal>, qui représentent basiquement la relation qui a été
    donné comme objet (mais avec une signification spéciale).
</para>

   <para>
    Donc, nous avons trois cas qui produisent les arbres de requêtes suivants
    pour une règle à une seule action.

    <variablelist>
     <varlistentry>
      <term>sans qualification avec soit <literal>ALSO</literal> soit <literal>INSTEAD</literal></term>
      <listitem>
       <para>
        l'arbre de requête à partir de l'action de la règle avec l'ajout de la
        qualification de l'arbre de requête original
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>qualification donnée et <literal>also</literal></term>
      <listitem>
       <para>
        l'arbre de requête à partir de l'action de la règle avec l'ajout de la
        qualification de la règle et de la qualification de l'arbre de requête
        original
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>qualification donnée avec <literal>instead</literal></term>
      <listitem>
       <para>
        l'arbre de requête à partir de l'action de la règle avec la
        qualification de la requête et la qualification de l'arbre de requête
        original&nbsp;; et l'ajout de l'arbre de requête original avec la
        qualification inverse de la règle
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    Enfin, si la règle est <literal>also</literal>, l'arbre de requête
    original est ajouté à la liste. Comme seules les règles qualifiées
    <literal>instead</literal> ont déjà ajouté l'arbre de requête original, nous
    finissons avec un ou deux arbres de requête en sortie pour une règle avec
    une action.
</para>

<para>
    Pour les règles <literal>on insert</literal>, la requête originale (si elle n'est
    pas supprimée par <literal>instead</literal>) est réalisée avant toute action
    ajoutée par les règles. Ceci permet aux actions de voir les lignes insérées.
    Mais pour les règles <literal>on update</literal> et <literal>on delete</literal>, la
    requête originale est réalisée après les actions ajoutées par les règles.
    Ceci nous assure que les actions pourront voir les lignes à mettre à jour ou
    à supprimer&nbsp;; sinon, les actions pourraient ne rien faire parce
    qu'elles ne trouvent aucune ligne correspondant à leurs qualifications.
</para>

<para>
    Les arbres de requêtes générés à partir des actions de règles sont 
    envoyés de nouveau dans le système de réécriture et peut-être que d'autres
    règles seront appliquées résultant en plus ou moins d'arbres de requêtes.
    Donc, les actions d'une règle doivent avoir soit un type de commande
    différent soit une relation résultante différente de celle où la règle
    elle-même est active, sinon ce processus récursif se terminera dans une
    boucle infinie. (L'expansion récursive d'une règle sera détectée et
    rapportée comme une erreur.)
</para>

<para>
    Les arbres de requête trouvés dans les actions du catalogue système
    <structname>pg_rewrite</structname> sont seulement des modèles. comme ils
    peuvent référencer les entrées de la table d'échelle pour <literal>new</literal> et
    <literal>old</literal>, quelques substitutions ont dû être faites avant qu'elles ne
    puissent être utilisées. Pour toute référence de <literal>new</literal>, une entrée
    correspondante est recherchée dans la liste cible de la requête originale.
    Si elle est trouvée, cette expression de l'entrée remplace la référence.
    Sinon, <literal>new</literal> signifie la même chose que <literal>old</literal> (pour un
    <command>update</command>) ou est remplacé par une valeur null (pour un
    <command>insert</command>). toute référence à <literal>old</literal> est remplacée
    par une référence à l'entrée de la table d'échelle qui est la relation
    résultante.
</para>

<para>
    Après que le système a terminé d'appliquer des règles de mise à jour, il 
    applique les règles de vues pour le(s) arbre(s) de requête produit(s). Les
    vues ne peuvent pas insérer de nouvelles actions de mise à jour, donc il
    n'est pas nécessaire d'appliquer les règles de mise à jour à la sortie d'une
    réécriture de vue.
</para>

<sect3>
<title>Une première requête étape par étape</title>

<para>
    Disons que nous voulons tracer les modifications dans la colonne
    <literal>dispo_lacet</literal> de la relation <literal>donnees_lacet</literal>. donc,
    nous allons configurer une table de traces et une règle qui va écrire une
    entrée lorsqu'un <command>update</command> est lancé sur
    <literal>donnees_lacet</literal>.

<programlisting>CREATE TABLE lacet_log (
    nom_lacet    text,          -- modification de lacet
    dispo_lacet   integer,       -- nouvelle valeur disponible
    log_who    text,          -- qui l'a modifié
    log_when   timestamp      -- quand
);

CREATE RULE log_lacet AS ON UPDATE TO donnees_lacet
    WHERE NEW.dispo_lacet &lt;&gt; OLD.dispo_lacet
    DO INSERT INTO lacet_log VALUES (
                                    NEW.nom_lacet,
                                    NEW.dispo_lacet,
                                    current_user,
                                    current_timestamp
                                );
</programlisting>
</para>

<para>
    Maintenant, quelqu'un exécute&nbsp;:

<programlisting>UPDATE donnees_lacet SET dispo_lacet = 6 WHERE nom_lacet = 'sl7';
</programlisting>

    et voici le contenu de la table des traces&nbsp;:

<programlisting>SELECT * FROM lacet_log;

 nom_lacet | dispo_lacet | log_who | log_when                        
-----------+-------------+---------+----------------------------------
 sl7       |           6 | Al      | Tue Oct 20 16:14:45 1998 MET DST
(1 row)
</programlisting>
   </para>

   <para>
    C'est ce à quoi nous nous attendions. Voici ce qui s'est passé en tâche
    de fond. L'analyseur a créé l'arbre de requête&nbsp;:

<programlisting>UPDATE donnees_lacet SET dispo_lacet = 6
  FROM donnees_lacet donnees_lacet
 WHERE donnees_lacet.nom_lacet = 'sl7';
</programlisting>

    Il existe une règle <literal>log_lacet</literal> qui est <literal>on
    UPDATE</literal> avec l'expression de qualification de la règle&nbsp;:

<programlisting>NEW.dispo_lacet &lt;&gt; OLD.dispo_lacet
</programlisting>

    et l'action&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       *NEW*.nom_lacet, *NEW*.dispo_lacet,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*;
</programlisting>

    (ceci semble un peu étrange car, normalement, vous ne pouvez pas écrire
    <literal>insert ... values ... from</literal>. ici, la clause <literal>from</literal>
    indique seulement qu'il existe des entrées de la table d'échelle dans
    l'arbre de requête pour <literal>*new*</literal> et <literal>*old*</literal>. elles sont
    nécessaires pour qu'elles puissent être référencées par des variables dans
    l'arbre de requête de la commande <command>insert</command>).
</para>

<para>
    La règle est une règle qualifiée <literal>also</literal> de façon à ce que
    le système de règles doit renvoyer deux arbres de requêtes&nbsp;: l'action
    de la règle modifiée et l'arbre de requête original. Dans la première
    étape, la table d'échelle de la requête originale est incorporée dans l'arbre
    de requête d'action de la règle. Ceci a pour résultat&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       *NEW*.nom_lacet, *NEW*.dispo_lacet,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*,
       <emphasis>donnees_lacet donnees_lacet</emphasis>;
</programlisting>

    Pour la deuxième étape, la qualification de la règle lui est ajoutée, donc
    l'ensemble de résultat est restreint aux lignes où <literal>dispo_lacet</literal> a
    changé&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       *NEW*.nom_lacet, *NEW*.dispo_lacet,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*,
       donnees_lacet donnees_lacet
 <emphasis>where *new*.dispo_lacet &lt;&gt; *old*.dispo_lacet</emphasis>;
</programlisting>

    (Ceci semble encore plus étrange car <literal>insert ... values</literal> n'a pas
    non plus une clause <literal>where</literal> mais le planificateur et l'exécuteur
    n'auront pas de difficultés avec ça. Ils ont besoin de supporter cette même 
    fonctionnalité pour <literal>insert ... select</literal>.)
   </para>

   <para>
    À l'étape 3, la qualification de l'arbre de requête original est ajoutée,
    restreignant encore plus l'ensemble de résultats pour les seules lignes qui
    auront été modifiées par la requête originale&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       *NEW*.nom_lacet, *NEW*.dispo_lacet,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*,
       donnees_lacet donnees_lacet
 WHERE *NEW*.dispo_lacet &lt;&gt; *OLD*.dispo_lacet
   <emphasis>and donnees_lacet.nom_lacet = 'sl7'</emphasis>;
</programlisting>
   </para>

   <para>
    La quatrième étape remplace les références à <literal>new</literal> par les
    entrées de la liste cible à partir de l'arbre de requête original ou par les
    références de la variable correspondante à partir de la relation
    résultat&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       <emphasis>donnees_lacet.nom_lacet</emphasis>, <emphasis>6</emphasis>,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*,
       donnees_lacet donnees_lacet
 WHERE <emphasis>6</emphasis> &lt;&gt; *old*.dispo_lacet
   AND donnees_lacet.nom_lacet = 'sl7';
</programlisting>

   </para>

   <para>
    L'étape 5 modifie les références <literal>old</literal> en référence de la
    relation résultat&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       donnees_lacet.nom_lacet, 6,
       current_user, current_timestamp )
  FROM donnees_lacet *NEW*, donnees_lacet *OLD*,
       donnees_lacet donnees_lacet
 WHERE 6 &lt;&gt; <emphasis>donnees_lacet.dispo_lacet</emphasis>
   AND donnees_lacet.nom_lacet = 'sl7';
</programlisting>
   </para>

   <para>
    C'est tout. Comme la règle est de type <literal>also</literal>, nous
    affichons aussi l'arbre de requêtes original. En bref, l'affichage à partir
    du système de règles est une liste de deux arbres de requêtes est une liste
    de deux arbres de requêtes correspondant à ces instructions&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       donnees_lacet.nom_lacet, 6,
       current_user, current_timestamp )
  FROM donnees_lacet
 WHERE 6 &lt;&gt; donnees_lacet.dispo_lacet
   AND donnees_lacet.nom_lacet = 'sl7';

UPDATE donnees_lacet SET dispo_lacet = 6
 WHERE nom_lacet = 'sl7';
</programlisting>

    Elles sont exécutées dans cet ordre et c'est exactement le but de la règle.
   </para>

   <para>
    Les substitutions et les qualifications ajoutées nous assurent que, si la
requête originale était&nbsp;:

<programlisting>UPDATE donnees_lacet SET couleur_lacet = 'green'
 WHERE nom_lacet = 'sl7';
</programlisting>

    aucune trace ne serait écrite. Dans ce cas, l'arbre de requête original ne
contient pas une entrée dans la liste cible pour <literal>dispo_lacet</literal>, donc
<literal>new.dispo_lacet</literal> sera remplacé par <literal>donnees_lacet.dispo_lacet</literal>. 
Du coup, la commande supplémentaire générée par la règle est&nbsp;:

<programlisting>INSERT INTO lacet_log VALUES (
       donnees_lacet.nom_lacet, <emphasis>donnees_lacet.dispo_lacet</emphasis>,
       current_user, current_timestamp )
  FROM donnees_lacet
 WHERE <emphasis>donnees_lacet.dispo_lacet</emphasis> &lt;&gt; donnees_lacet.dispo_lacet
   AND donnees_lacet.nom_lacet = 'sl7';
</programlisting>

    et la qualification ne sera jamais vraie.
   </para>

   <para>
    Si la requête originale modifie plusieurs lignes, cela fonctionne aussi.
    Donc, si quelqu'un a lancé la commande&nbsp;:

<programlisting>UPDATE donnees_lacet SET dispo_lacet = 0
 WHERE couleur_lacet = 'black';
</programlisting>

    en fait, quatre lignes sont modifiées (<literal>sl1</literal>, <literal>sl2</literal>,
    <literal>sl3</literal> et <literal>sl4</literal>). mais <literal>sl3</literal> a déjà
    <literal>dispo_lacet = 0</literal>. dans ce cas, la qualification des arbres de
    requêtes originaux sont différents et cela produit un arbre de requête
    supplémentaire&nbsp;:

<programlisting>INSERT INTO lacet_log
SELECT donnees_lacet.nom_lacet, 0,
       current_user, current_timestamp
  FROM donnees_lacet
 WHERE 0 &lt;&gt; donnees_lacet.dispo_lacet
   AND <emphasis>donnees_lacet.couleur_lacet = 'black'</emphasis>;
</programlisting>

    à générer par la règle. Cet arbre de requête aura sûrement inséré trois
nouvelles lignes de traces. Et c'est tout à fait correct.
</para>

<para>
    Ici, nous avons vu pourquoi il est important que l'arbre de requête
    original soit exécuté en premier. Si l'<command>update</command> a été
    exécuté avant, toutes les lignes pourraient aussi être initialisées à zéro,
    donc le <command>insert</command> tracé ne trouvera aucune ligne à
    <literal>0 &lt;&gt; donnees_lacet.dispo_lacet</literal>.
</para>
</sect3>

</sect2>

<sect2 id="rules-update-views">
<title>Coopération avec les vues</title>

<indexterm zone="rules-update-views"><primary>vue</primary><secondary>mise à jour</secondary></indexterm>

<para>
    Une façon simple de protéger les vues d'une exécution
    d'<command>insert</command>, d'<command>update</command> ou de
    <command>delete</command> sur elles est de
    laisser s'abandonner ces arbres de requête. Donc, nous pourrions créer les
    règles&nbsp;:

<programlisting>CREATE RULE chaussure_ins_protect AS ON INSERT TO chaussure
    DO INSTEAD NOTHING;
CREATE RULE chaussure_upd_protect AS ON UPDATE TO chaussure
    DO INSTEAD NOTHING;
CREATE RULE chaussure_del_protect AS ON DELETE TO chaussure
    DO INSTEAD NOTHING;
</programlisting>

    Maintenant, si quelqu'un essaie de faire une de ces opérations sur la
    vue <literal>chaussure</literal>, le système de règles appliquera ces règles.
    Comme les règles n'ont pas d'action et sont de type <literal>instead</literal>, la
    liste résultante des arbres de requêtes sera vide et la requête entière 
    deviendra vide car il ne reste rien à optimiser ou exécuter après que le
    système de règles en ait terminé avec elle.
</para>

<para>
    Une façon plus sophistiquée d'utiliser le système de règles est de créer 
    les règles qui réécrivent l'arbre de requête en un arbre faisant la bonne
    opération sur les vraies tables. Pour réaliser cela sur la vue
    <literal>lacet</literal>, nous créons les règles suivantes&nbsp;:

<programlisting>CREATE RULE lacet_ins AS ON INSERT TO lacet
    DO INSTEAD
    INSERT INTO donnees_lacet VALUES (
           NEW.nom_lacet,
           NEW.dispo_lacet,
           NEW.couleur_lacet,
           NEW.longueur_lacet,
           NEW.unite_lacet
    );

CREATE RULE lacet_upd AS ON UPDATE TO lacet
    DO INSTEAD
    UPDATE donnees_lacet
       SET nom_lacet = NEW.nom_lacet,
           dispo_lacet = NEW.dispo_lacet,
           couleur_lacet = NEW.couleur_lacet,
           longueur_lacet = NEW.longueur_lacet,
           unite_lacet = NEW.unite_lacet
     WHERE nom_lacet = OLD.nom_lacet;

CREATE RULE lacet_del AS ON DELETE TO lacet
    DO INSTEAD
    DELETE FROM donnees_lacet
     WHERE nom_lacet = OLD.nom_lacet;
</programlisting>
   </para>

   <para>
    Si vous voulez supporter les requêtes <literal>RETURNING</literal> sur la vue,
    vous devrez faire en sorte que les règles incluent les clauses
    <literal>RETURNING</literal> qui calcule les lignes de la vue. Ceci est assez
    simple pour des vues sur une seule table mais cela devient rapidement complexe
    pour des vues de jointure comme <literal>lacet</literal>. Voici un exemple
    pour le cas d'un INSERT&nbsp;:

<programlisting>CREATE RULE lacet_ins AS ON INSERT TO lacet
    DO INSTEAD
    INSERT INTO donnees_lacet VALUES (
           NEW.nom_lacet,
	   NEW.dispo_lacet,
	   NEW.couleur_lacet,
	   NEW.longueur_lacet,
	   NEW.unite_lacet
    )
    RETURNING
           donnees_lacet.*,
	   (SELECT donnees_lacet.longueur_lacet * u.facteur_unite
            FROM unite u WHERE donnees_lacet.unite_lacet = u.nom_unite);
</programlisting>

    Notez que cette seule règle supporte à la fois les <command>INSERT</command>
    et les <command>INSERT RETURNING</command> sur la vue &mdash; la clause
    <literal>RETURNING</literal> est tout simplement ignoré pour un <command>INSERT</command>.
   </para>

   <para>
    Maintenant, supposons que, quelque fois, un paquet de lacets arrive au 
    magasin avec une grosse liste. Mais vous ne voulez pas mettre à jour
    manuellement la vue <literal>lacet</literal> à chaque fois. à la place,
    nous configurons deux petites tables, une où vous pouvez insérer les
    éléments de la liste et une avec une astuce spéciale. Voici les commandes de
    création&nbsp;:

<programlisting>CREATE TABLE lacet_arrive (
    arr_name    text,
    arr_quant   integer
);

CREATE TABLE lacet_ok (
    ok_name     text,
    ok_quant    integer
);

CREATE RULE lacet_ok_ins AS ON INSERT TO lacet_ok
    DO INSTEAD
    UPDATE lacet
       SET dispo_lacet = dispo_lacet + NEW.ok_quant
     WHERE nom_lacet = NEW.ok_name;
</programlisting>

    Maintenant, vous pouvez remplir la table <literal>lacet_arrive</literal>
    avec les données de la liste&nbsp;:

<programlisting>SELECT * FROM lacet_arrive;

 arr_name | arr_quant
----------+-----------
 sl3      |        10
 sl6      |        20
 sl8      |        20
(3 rows)
</programlisting>

    Jetez un &oelig;il rapidement aux données actuelles&nbsp;:
    
<programlisting>SELECT * FROM lacet;

 nom_lacet  | dispo_lacet | couleur_lacet | longueur_lacet | unite_lacet | longueur_lacet_cm
------------+-------------+---------------+----------------+-------------+-------------------
 sl1        |           5 | black         |             80 | cm          |                80
 sl2        |           6 | black         |            100 | cm          |               100
 sl7        |           6 | brown         |             60 | cm          |                60
 sl3        |           0 | black         |             35 | inch        |              88.9
 sl4        |           8 | black         |             40 | inch        |             101.6
 sl8        |           1 | brown         |             40 | inch        |             101.6
 sl5        |           4 | brown         |              1 | m           |               100
 sl6        |           0 | brown         |            0.9 | m           |                90
(8 rows)
</programlisting>

    Maintenant, déplacez les lacets arrivés dans&nbsp;:

<programlisting>INSERT INTO lacet_ok SELECT * FROM lacet_arrive;
</programlisting>

    et vérifiez le résultat&nbsp;:

<programlisting>SELECT * FROM lacet ORDER BY nom_lacet;

 nom_lacet  | dispo_lacet | couleur_lacet | longueur_lacet | unite_lacet | longueur_lacet_cm
------------+-------------+---------------+----------------+-------------+-------------------
 sl1        |           5 | black         |             80 | cm          |                80
 sl2        |           6 | black         |            100 | cm          |               100
 sl7        |           6 | brown         |             60 | cm          |                60
 sl4        |           8 | black         |             40 | inch        |             101.6
 sl3        |          10 | black         |             35 | inch        |              88.9
 sl8        |          21 | brown         |             40 | inch        |             101.6
 sl5        |           4 | brown         |              1 | m           |               100
 sl6        |          20 | brown         |            0.9 | m           |                90
(8 rows)

SELECT * FROM lacet_log;

 nom_lacet | dispo_lacet | log_who| log_when                        
-----------+-------------+--------+----------------------------------
 sl7       |           6 | Al     | Tue Oct 20 19:14:45 1998 MET DST
 sl3       |          10 | Al     | Tue Oct 20 19:25:16 1998 MET DST
 sl6       |          20 | Al     | Tue Oct 20 19:25:16 1998 MET DST
 sl8       |          21 | Al     | Tue Oct 20 19:25:16 1998 MET DST
(4 rows)
</programlisting>
   </para>

   <para>
    C'est un long chemin du <literal>insert ... select</literal> à ces
    résultats. Et la description de la transformation de l'arbre de requêtes
    sera la dernière dans ce chapitre. Tout d'abord, voici la sortie de
    l'analyseur&nbsp;:

<programlisting>INSERT INTO lacet_ok
SELECT lacet_arrive.arr_name, lacet_arrive.arr_quant
  FROM lacet_arrive lacet_arrive, lacet_ok lacet_ok;
</programlisting>

    Maintenant, la première règle <literal>lacet_ok_ins</literal> est
    appliquée et transforme ceci en&nbsp;:

<programlisting>UPDATE lacet
   SET dispo_lacet = lacet.dispo_lacet + lacet_arrive.arr_quant
  FROM lacet_arrive lacet_arrive, lacet_ok lacet_ok,
       lacet_ok *OLD*, lacet_ok *NEW*,
       lacet lacet
 WHERE lacet.nom_lacet = lacet_arrive.arr_name;
</programlisting>

    et jette l'<command>insert</command> actuel sur
    <literal>lacet_ok</literal>. la requête réécrite est passée de nouveau 
    au système de règles et la seconde règle appliquée
    <literal>lacet_upd</literal> produit&nbsp;:

<programlisting>UPDATE donnees_lacet
   SET nom_lacet = lacet.nom_lacet,
       dispo_lacet = lacet.dispo_lacet + lacet_arrive.arr_quant,
       couleur_lacet = lacet.couleur_lacet,
       longueur_lacet = lacet.longueur_lacet,
       unite_lacet = lacet.unite_lacet
  FROM lacet_arrive lacet_arrive, lacet_ok lacet_ok,
       lacet_ok *OLD*, lacet_ok *NEW*,
       lacet lacet, lacet *OLD*,
       lacet *NEW*, donnees_lacet donnees_lacet
 WHERE lacet.nom_lacet = lacet_arrive.arr_name
   AND donnees_lacet.nom_lacet = lacet.nom_lacet;
</programlisting>

    De nouveau, il s'agit d'une règle <literal>instead</literal> et l'arbre de
    requête précédent est jeté. Notez que cette requête utilise toujours la vue
    <literal>lacet</literal>. mais le système de règles n'a pas fini cette
    étape, donc il continue et lui applique la règle <literal>_return</literal>.
    Nous obtenons&nbsp;:

<programlisting>UPDATE donnees_lacet
   SET nom_lacet = s.nom_lacet,
       dispo_lacet = s.dispo_lacet + lacet_arrive.arr_quant,
       couleur_lacet = s.couleur_lacet,
       longueur_lacet = s.longueur_lacet,
       unite_lacet = s.unite_lacet
  FROM lacet_arrive lacet_arrive, lacet_ok lacet_ok,
       lacet_ok *OLD*, lacet_ok *NEW*,
       lacet lacet, lacet *OLD*,
       lacet *NEW*, donnees_lacet donnees_lacet,
       lacet *OLD*, lacet *NEW*,
       donnees_lacet s, unit u
 WHERE s.nom_lacet = lacet_arrive.arr_name
   AND donnees_lacet.nom_lacet = s.nom_lacet;
</programlisting>

    Enfin, la règle <literal>log_lacet</literal> est appliquée, produisant
    l'arbre de requête supplémentaire&nbsp;:

<programlisting>INSERT INTO lacet_log
SELECT s.nom_lacet,
       s.dispo_lacet + lacet_arrive.arr_quant,
       current_user,
       current_timestamp
  FROM lacet_arrive lacet_arrive, lacet_ok lacet_ok,
       lacet_ok *OLD*, lacet_ok *NEW*,
       lacet lacet, lacet *OLD*,
       lacet *NEW*, donnees_lacet donnees_lacet,
       lacet *OLD*, lacet *NEW*,
       donnees_lacet s, unit u,
       donnees_lacet *OLD*, donnees_lacet *NEW*
       lacet_log lacet_log
 WHERE s.nom_lacet = lacet_arrive.arr_name
   AND donnees_lacet.nom_lacet = s.nom_lacet
   AND (s.dispo_lacet + lacet_arrive.arr_quant) &lt;&gt; s.dispo_lacet;
</programlisting>

    une fois que le système de règles tombe en panne de règles et renvoie
    les arbres de requêtes générés.
   </para>

   <para>
    Donc, nous finissons avec deux arbres de requêtes finaux qui sont
    équivalents aux instructions <acronym>SQL</acronym>&nbsp;:

<programlisting>INSERT INTO lacet_log
SELECT s.nom_lacet,
       s.dispo_lacet + lacet_arrive.arr_quant,
       current_user,
       current_timestamp
  FROM lacet_arrive lacet_arrive, donnees_lacet donnees_lacet,
       donnees_lacet s
 WHERE s.nom_lacet = lacet_arrive.arr_name
   AND donnees_lacet.nom_lacet = s.nom_lacet
   AND s.dispo_lacet + lacet_arrive.arr_quant &lt;&gt; s.dispo_lacet;
           
UPDATE donnees_lacet
   SET dispo_lacet = donnees_lacet.dispo_lacet + lacet_arrive.arr_quant
  FROM lacet_arrive lacet_arrive,
       donnees_lacet donnees_lacet,
       donnees_lacet s
 WHERE s.nom_lacet = lacet_arrive.nom_lacet
   AND donnees_lacet.nom_lacet = s.nom_lacet;
</programlisting>

    Le résultat est que la donnée provenant d'une relation insérée dans une
    autre, modifiée en mise à jour dans une troisième, modifiée en mise
    à jour dans une quatrième, cette dernière étant tracée dans une cinquième,
    se voit réduite à deux requêtes.
</para>

<para>
    Il y a un petit détail assez horrible. En regardant les deux requêtes, nous
    nous apercevons que la relation <literal>donnees_lacet</literal> apparaît
    deux fois dans la table d'échelle où cela pourrait être réduit à une seule
    occurrence. Le planificateur ne gère pas ceci et, du coup, le plan
    d'exécution de la sortie du système de règles pour <command>insert</command>
    sera&nbsp;:

<literallayout class="monospaced">Nested Loop
  -&gt;  Merge Join
        -&gt;  Seq Scan
              -&gt;  Sort
                    -&gt;  Seq Scan on s
        -&gt;  Seq Scan
              -&gt;  Sort
                    -&gt;  Seq Scan on lacet_arrive
  -&gt;  Seq Scan on donnees_lacet
</literallayout>

    alors qu'omettre la table d'échelle supplémentaire résulterait en un&nbsp;:

<literallayout class="monospaced">Merge Join
  -&gt;  Seq Scan
        -&gt;  Sort
              -&gt;  Seq Scan on s
  -&gt;  Seq Scan
        -&gt;  Sort
              -&gt;  Seq Scan on lacet_arrive
</literallayout>

    qui produit exactement les mêmes entrées dans la table des traces. Du
    coup, le système de règles a causé un parcours supplémentaire dans la table
    <literal>donnees_lacet</literal> qui n'est absolument pas nécessaire. et le
    même parcours redondant est fait une fois de plus dans
    l'<command>update</command>. mais ce fut réellement un travail difficile de
    rendre tout ceci possible.
</para>

<para>
    Maintenant, nous faisons une démonstration finale du système de règles de
    <productname>PostgreSQL</productname> et de sa puissance. disons que nous
    ajoutons quelques lacets avec des couleurs extraordinaires à votre base de
    données&nbsp;:

<programlisting>INSERT INTO lacet VALUES ('sl9', 0, 'pink', 35.0, 'inch', 0.0);
INSERT INTO lacet VALUES ('sl10', 1000, 'magenta', 40.0, 'inch', 0.0);
</programlisting>

    Nous voulons créer une vue vérifiant les entrées
    <literal>lacet</literal> qui ne correspondent à aucune chaussure pour
    la couleur. Voici la vue&nbsp;:

<programlisting>CREATE VIEW lacet_mismatch AS
    SELECT * FROM lacet WHERE NOT EXISTS
        (SELECT nom_chaussure FROM chaussure WHERE couleur = couleur_lacet);
</programlisting>

    Sa sortie est&nbsp;:

<programlisting>SELECT * FROM lacet_mismatch;

 nom_lacet | dispo_lacet | couleur_lacet | longueur_lacet | unite_lacet | longueur_lacet_cm
-----------+-------------+---------------+----------------+-------------+-------------------
 sl9       |           0 | pink          |             35 | inch        |              88.9
 sl10      |        1000 | magenta       |             40 | inch        |             101.6
</programlisting>
   </para>

   <para>
    Maintenant, nous voulons la configurer pour que les lacets qui ne
    correspondent pas et qui ne sont pas en stock soient supprimés de la base de
    données. Pour rendre la chose plus difficile à
    <productname>PostgreSQL</productname>, nous ne les supprimons pas
    directement. À la place, nous créons une vue supplémentaire&nbsp;:

<programlisting>CREATE VIEW lacet_can_delete AS
    SELECT * FROM lacet_mismatch WHERE dispo_lacet = 0;
</programlisting>

    et le faisons de cette façon&nbsp;:

<programlisting>DELETE FROM lacet WHERE EXISTS
    (SELECT * FROM lacet_can_delete
             WHERE nom_lacet = lacet.nom_lacet);
</programlisting>

    <foreignphrase>voilà</foreignphrase>&nbsp;:

<programlisting>SELECT * FROM lacet;

 nom_lacet | dispo_lacet | couleur_lacet | longueur_lacet | unite_lacet | longueur_lacet_cm
-----------+-------------+---------------+----------------+-------------+-------------------
 sl1       |           5 | black         |             80 | cm          |                80
 sl2       |           6 | black         |            100 | cm          |               100
 sl7       |           6 | brown         |             60 | cm          |                60
 sl4       |           8 | black         |             40 | inch        |             101.6
 sl3       |          10 | black         |             35 | inch        |              88.9
 sl8       |          21 | brown         |             40 | inch        |             101.6
 sl10      |        1000 | magenta       |             40 | inch        |             101.6
 sl5       |           4 | brown         |              1 | m           |               100
 sl6       |          20 | brown         |            0.9 | m           |                90
(9 rows)
</programlisting>
   </para>

   <para>
    Un <command>delete</command> sur une vue, avec une qualification de
    sous-requête qui utilise au total quatre vues imbriquées/jointes, où l'une
    d'entre elles a une qualification de sous-requête contenant une vue et où
    les colonnes des vues calculées sont utilisées, est réécrite en un seul
    arbre de requête qui supprime les données demandées sur la vraie table.
</para>

<para>
    Il existe probablement seulement quelques situations dans le vrai monde où
    une telle construction est nécessaire. Mais, vous vous sentez mieux quand
    cela fonctionne.
</para>
</sect2>

</sect1>

<sect1 id="rules-privileges">
<title>Règles et droits</title>

<indexterm zone="rules-privileges">
 <primary>droit</primary>
 <secondary sortas="regeln">avec les règles</secondary>
</indexterm>

<indexterm zone="rules-privileges">
 <primary>droit</primary>
 <secondary sortas="sichten">avec les vues</secondary>
</indexterm>

<para>
    À cause de la réécriture des requêtes par le système de règles de
    <productname>PostgreSQL</productname>, d'autres tables/vues que celles
    utilisées dans la requête originale pourraient être accédées. Lorsque des
    règles de mise à jour sont utilisées, ceci peut inclure des droits
    d'écriture sur les tables.
</para>

<para>
    Les règles de réécriture n'ont pas de propriétaire séparé. Le propriétaire
    d'une relation (table ou vue) est automatiquement le propriétaire des règles
    de réécriture qui lui sont définies. Le système de règles de
    <productname>PostgreSQL</productname> modifie le comportement du système de
    contrôle d'accès par défaut. Les relations qui sont utilisées à cause des
    règles se voient vérifier avec les droits du propriétaire de la règle, et
    non avec ceux de l'utilisateur appelant cette règle. Ceci signifie qu'un
    utilisateur a seulement besoin des droits requis pour les tables/vues qu'il
    nomme explicitement dans ses requêtes.
</para>

<para>
    Par exemple&nbsp;: un utilisateur a une liste de numéros de téléphone dont
    certains sont privés, les autres étant d'intérêt pour la secrétaire du
    bureau. Il peut construire de cette façon&nbsp;:

<programlisting>CREATE TABLE phone_data (person text, phone text, private boolean);
CREATE VIEW phone_number AS
    SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;
</programlisting>
    
    Personne sauf lui (et les superutilisateurs de la base de données) ne peut
    accéder à la table <literal>phone_data</literal>. mais, à cause du 
    <command>grant</command>, la secrétaire peut lancer un <command>select</command>
    sur la vue <literal>phone_number</literal>. le système de règles réécrira le
    <command>select</command> sur <literal>phone_number</literal> en un 
    <command>select</command> sur <literal>phone_data</literal> et ajoutera la
    qualification que seules les entrées non privées (donc où
    <literal>private</literal> est faux) sont désirées. comme l'utilisateur est le
    propriétaire de <literal>phone_number</literal> et du coup le propriétaire de la
    règle, le droit de lecture de <literal>phone_data</literal> est maintenant vérifié
    avec ses propres privilèges et la requête est autorisée. La vérification de
    l'accès à <literal>phone_number</literal> est aussi réalisée mais ceci est fait
    avec l'utilisateur appelant, donc personne sauf l'utilisateur et la
    secrétaire ne peut l'utiliser.
</para>

<para>
    Les droits sont vérifiés règle par règle. Donc, la secrétaire est
    actuellement la seule à pouvoir voir les numéros de téléphone publiques.
    Mais la secrétaire peut configurer une autre vue et autoriser l'accès au
    public. Du coup, tout le monde peut voir les données de
    <literal>phone_number</literal> via la vue de la secrétaire. ce que la secrétaire
    ne peut pas faire est de créer une vue qui accède directement à
    <literal>phone_data</literal> (en fait, elle le peut mais cela ne fonctionnera pas car
    tous les accès seront refusés lors de la vérification des droits). Dès que
    l'utilisateur s'en rendra compte, du fait que la secrétaire a ouvert la vue
    <literal>phone_number</literal> à tout le monde, il peut révoquer son accès.
    Immédiatement, tous les accès de la vue de la secrétaire échoueront.
</para>

<para>
    Il pourrait être dit que cette vérification règle par règle est une brèche
    de sécurité mais ce n'est pas le cas. Si cela ne fonctionne pas de cette
    façon, la secrétaire pourrait copier une table avec les mêmes colonnes que
    <literal>phone_number</literal> et y copier les données une fois par jour. du coup,
    ce sont ces propres données et elle peut accorder l'accès à tout le monde si
    elle le souhaite. Une commande <command>grant</command> signifie <quote>j'ai
    confiance en vous</quote>. si quelqu'un en qui vous avez confiance se
    comporte ainsi, il est temps d'y réfléchir et d'utiliser
    <command>revoke</command>.
</para>

<para>
    Ce mécanisme fonctionne aussi pour les règles de mise à jour. Dans les
    exemples de la section précédente, le propriétaire des tables de la base de
    données d'exemple pourrait accorder les droits <literal>select</literal>,
    <literal>insert</literal>, <literal>update</literal> et <literal>delete</literal> sur la vue
    <literal>lacet</literal> à quelqu'un d'autre mais seulement <literal>select</literal>
    sur <literal>lacet_log</literal>. l'action de la règle pourrait écrire des
    entrées de trace qui seraient toujours exécutées avec succès et que l'autre
    utilisateur pourrait voir. Mais il ne peut pas créer d'entrées fausses, pas
    plus qu'il ne peut manipuler ou supprimer celles qui existent.
</para>
</sect1>

<sect1 id="rules-status">
<title>Règles et statut de commande</title>

<para>
    Le serveur <productname>PostgreSQL</productname> renvoie une chaîne de
    statut de commande, comme <literal>insert 149592 1</literal>, pour chaque commande
    qu'il reçoit. C'est assez simple lorsqu'il n'y a pas de règles impliquées.
    Mais qu'arrive-t'il lorsque la requête est réécrite par des règles&nbsp;?
</para>

<para>
    Les règles affectent le statut de la commande de cette façon&nbsp;:

    <itemizedlist>
     <listitem>
      <para>
       S'il n'y a pas de règle <literal>instead</literal> inconditionnelle pour la
       requête, alors la requête donnée originellement sera exécutée et son
       statut de commande sera renvoyé comme d'habitude. (Mais notez que s'il y
       avait des règles <literal>instead</literal> conditionnelles, la négation de leur
       qualifications sera ajouté à la requête initiale. Ceci pourrait réduire
       le nombre de lignes qu'il traite et, si c'est le cas, le statut rapporté
       en sera affecté.)
      </para>
     </listitem>

     <listitem>
      <para>
       S'il y a des règles <literal>instead</literal> inconditionnelles pour la
       requête, alors la requête originale ne sera pas exécutée du tout. Dans ce
       cas, le serveur renverra le statut de la commande pour la dernière
       requête qui a été insérée par une règle <literal>instead</literal>
       (conditionnelle ou non) et est du même type de commande
       (<command>insert</command>, <command>update</command> ou
       <command>delete</command>) que la requête originale. si aucune requête ne
       rencontrant ces pré-requis n'est ajoutée à une règle, alors le statut de
       commande renvoyé affiche le type de requête original et annule le
       compteur de ligne et le champ OID.
      </para>
     </listitem>
    </itemizedlist>

    (Ce système a été établi pour <productname>PostgreSQL</productname> 7.3.
    Dans les versions précédentes, le statut de commande pouvait afficher des
    résultats différents lorsque les règles existaient.)
</para>

<para>
    Le programmeur peut s'assurer que toute règle <literal>instead</literal> désirée
    est celle qui initialise le statut de commande dans le deuxième cas en
    lui donnant un nom de règle étant le dernier en ordre alphabétique parmi les
    règles actives pour qu'elle soit appliquée en dernier.
</para>
</sect1>

<sect1 id="rules-triggers">
<title>Règles contre déclencheurs</title>

<indexterm zone="rules-triggers">
 <primary>règle</primary>
 <secondary sortas="trigger">comparée aux déclencheurs</secondary>
</indexterm>

<indexterm zone="rules-triggers">
 <primary>déclencheur</primary>
 <secondary sortas="regeln">comparé aux règles</secondary>
</indexterm>

<para>
    Beaucoup de choses pouvant se faire avec des déclencheurs peuvent aussi
    être implémentées en utilisant le système de règles de
    <productname>PostgreSQL</productname>. un des points qui ne pourra pas être
    implémenté par les règles en certains types de contraintes, notamment les
    clés étrangères. Il est possible de placer une règle qualifiée qui réécrit
    une commande en <literal>nothing</literal> si la valeur d'une colonne n'apparaît
    pas dans l'autre table. Mais alors les données sont jetées et ce n'est pas
    une bonne idée. Si des vérifications de valeurs valides sont requises et
    dans le cas où il y a une erreur invalide, un message d'erreur devrait être
    généré et cela devra se faire avec un déclencheur.
</para>

<para>
    D'un autre côté, un déclencheur qui est lancé sur un
    <command>insert</command> pour une vue peut faire la même chose qu'une
    règle&nbsp;: placez les données ailleurs et supprimez les insertions dans la
    vue. Mais, il ne pourra pas faire la même chose avec un
    <command>update</command> ou un <command>delete</command> parce qu'il n'y a
    pas de vraies données sur la vue qui pourraient être parcourues. Du coup, le
    déclencheur ne serait jamais appelé. Seule une règle pourra vous aider.
</para>

<para>
    Pour les éléments qui peuvent être implémentés par les deux, ce qui sera le
    mieux dépend de l'utilisation de la base de données. Un déclencheur
    est exécuté une fois pour chaque ligne affectée. Une règle manipule la
    requête ou en génère une autre. Donc, si un grand nombre de lignes sont
    affectées pour une instruction, une règle lançant une commande supplémentaire
    sera certainement plus rapide qu'un déclencheur appelé pour chaque ligne et qui
    devra exécuter ces opérations autant de fois. Néanmoins, l'approche du
    déclencheur est conceptuellement plus simple que l'approche de la règle et est
    plus facile à utiliser pour les novices.
</para>

<para>
    Ici, nous montrons un exemple où le choix d'une règle ou d'un déclencheur
    joue sur une situation. Voici les deux tables&nbsp;:

<programlisting>CREATE TABLE ordinateur (
    nom_hote        text,    -- indexé
    constructeur    text     -- indexé
);

CREATE TABLE logiciel (
    logiciel        text,    -- indexé
    nom_hote        text     -- indexé
);
</programlisting>

    Les deux tables ont plusieurs milliers de lignes et les index sur
    <structfield>nom_hote</structfield> sont uniques. la règle ou le déclencheur devrait
    implémenter une contrainte qui supprime les lignes de <literal>logiciel</literal>
    référençant un ordinateur supprimé. Le déclencheur utiliserait cette
    commande&nbsp;:

<programlisting>DELETE FROM logiciel WHERE nom_hote = $1;
</programlisting>

    Comme le déclencheur est appelé pour chaque ligne individuelle supprimée à
 partir de <literal>ordinateur</literal>, il peut préparer et sauvegarder le plan pour
cette commande et passer la valeur <structfield>nom_hote</structfield> dans le paramètre.
La règle devra être réécrite ainsi&nbsp;:

<programlisting>CREATE RULE ordinateur_del AS ON DELETE TO ordinateur
    DO DELETE FROM logiciel WHERE nom_hote = OLD.nom_hote;
</programlisting>
   </para>

   <para>
    Maintenant, nous apercevons différents types de suppressions. Dans le cas
    d'un&nbsp;:
    
<programlisting>DELETE FROM ordinateur WHERE nom_hote = 'mypc.local.net';
</programlisting>

    la table <literal>ordinateur</literal> est parcourue par l'index (rapide), et la
    commande lancée par le déclencheur pourrait aussi utiliser un parcours
    d'index (aussi rapide). La commande supplémentaire provenant de la règle
serait&nbsp;:

<programlisting>DELETE FROM logiciel WHERE ordinateur.nom_hote = 'mypc.local.net'
                       AND logiciel.nom_hote = ordinateur.nom_hote;
</programlisting>

    Comme il y a une configuration appropriée des index, le planificateur
    créera un plan&nbsp;:

<literallayout class="monospaced">Nestloop
  -&gt;  Index Scan using comp_hostidx on ordinateur
  -&gt;  Index Scan using soft_hostidx on logiciel
</literallayout>

    Donc, il n'y aurait pas trop de différence de performance entre le
    déclencheur et l'implémentation de la règle.
   </para>

   <para>
    Avec la prochaine suppression, nous voulons nous débarrasser des 2000
ordinateurs où <structfield>nom_hote</structfield> commence avec <literal>old</literal>. il
existe deux commandes possibles pour ce faire. Voici l'une d'elle&nbsp;:

<programlisting>DELETE FROM ordinateur WHERE nom_hote &gt;= 'old'
                       AND nom_hote &lt;  'ole'
</programlisting>

    La commande ajoutée par la règle sera&nbsp;:

<programlisting>DELETE FROM logiciel WHERE ordinateur.nom_hote &gt;= 'old'
                       AND ordinateur.nom_hote &lt; 'ole'
                       AND logiciel.nom_hote = ordinateur.nom_hote;
</programlisting>

    avec le plan&nbsp;:

<literallayout class="monospaced">Hash Join
  -&gt;  Seq Scan on logiciel
  -&gt;  Hash
    -&gt;  Index Scan using comp_hostidx on ordinateur
</literallayout>

    L'autre commande possible est&nbsp;:

<programlisting>DELETE FROM ordinateur WHERE nom_hote ~ '^old';
</programlisting>

    ce qui finira dans le plan d'exécution suivant pour la commande ajoutée
    par la règle&nbsp;:

<literallayout class="monospaced">Nestloop
  -&gt;  Index Scan using comp_hostidx on ordinateur
  -&gt;  Index Scan using soft_hostidx on logiciel
</literallayout>

    Ceci monte que le planificateur ne réalise pas que la qualification pour
    <structfield>nom_hote</structfield> dans <literal>ordinateur</literal> pourrait aussi être
    utilisée pour un parcours d'index sur <literal>logiciel</literal> quand il existe
    plusieurs expressions de qualifications combinées avec <literal>and</literal>, ce
    qui correspond à ce qu'il fait dans la version expression rationnelle de la
    commande. Le déclencheur sera appelé une fois pour chacun des 2000 anciens
    ordinateurs qui doivent être supprimées, et ceci résultera en un parcours
    d'index sur <literal>ordinateur</literal> et 2000 parcours d'index sur
    <literal>logiciel</literal>. l'implémentation de la règle le fera en deux commandes
    qui utilisent les index. Et cela dépend de la taille globale de la table
    <literal>logiciel</literal>, si la règle sera toujours aussi rapide dans la
    situation du parcours séquentiel. 2000 exécutions de commandes à partir du
    déclencheur sur le gestionnaire SPI prend un peu de temps, même si tous les
    blocs d'index seront rapidement dans le cache.
</para>

<para>
    La dernière commande que nous regardons est&nbsp;:

<programlisting>DELETE FROM ordinateur WHERE constructeur = 'bim';
</programlisting>

    De nouveau, ceci pourrait résulter en de nombreuses lignes à supprimer dans
<literal>ordinateur</literal>. donc, le déclencheur lancera de nouveau de nombreuses
commandes via l'exécuteur. La commande générée par la règle sera&nbsp;:

<programlisting>DELETE FROM logiciel WHERE ordinateur.constructeur = 'bim'
                       AND logiciel.nom_hote = ordinateur.nom_hote;
</programlisting>

    Le plan pour cette commande sera encore la boucle imbriquée sur les deux
    parcours d'index, en utilisant seulement un index différent sur
    <literal>ordinateur</literal>&nbsp;:

<programlisting>Nestloop
  -&gt;  Index Scan using comp_manufidx on ordinateur
  -&gt;  Index Scan using soft_hostidx on logiciel
</programlisting>

    Dans chacun de ces cas, les commandes supplémentaires provenant du
    système de règles seront plus ou moins indépendantes du nombre de lignes
    affectées en une commande.
</para>

<!--[ignore[ what's happening with this?  if it doesn't come back, remove this section. 
<para>
    Another situation is cases on <command>UPDATE</command> where it depends on the
    change of an attribute if an action should be performed or
    not. The only way to
    create a rule as in the shoelace_log example is to do it with
    a rule qualification. That results in an extra query that is
    performed always, even if the attribute of interest cannot
    change at all because it does not appear in the target list
    of the initial query. When this is enabled again, it will be
    one more advantage of rules over triggers. Optimization of
    a trigger must fail by definition in this case, because the
    fact that its actions will only be done when a specific attribute
    is updated is hidden in its functionality. The definition of
    a trigger only allows to specify it on row level, so whenever a
    row is touched, the trigger must be called to make its
    decision. The rule system will know it by looking up the
    target list and will suppress the additional query completely
    if the attribute isn't touched. So the rule, qualified or not,
    will only do its scans if there ever could be something to do.
</para>
]]-->

<para>
    Voici le résumé, les règles seront seulement significativement plus lentes
    que les déclencheurs si leur actions résultent en des jointures larges et
    mal qualifiées, une situation où le planificateur échoue.
</para>
</sect1>

</chapter>