Ce chapitre discute du syst�me de r�gles dans PostgreSQL™. les syst�mes de r�gles de production sont simples conceptuellement mais il existe de nombreux points subtils impliqu�s dans leur utilisation.
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 PostgreSQL™, elles peuvent aussi �tre impl�ment�es en utilisant des fonctions et des d�clencheurs.
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 Stonebraker et al, ACM, 1990 et Ong and Goh, 1990.
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.
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 SQL.
Maintenant, qu'est-ce qu'un arbre de requ�tes ? C'est une repr�sentation interne d'une instruction SQL 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 debug_print_parse, debug_print_rewritten, ou debug_print_plan. les actions de r�gles sont aussi enregistr�es comme arbres de requ�tes dans le catalogue syst�me pg_rewrite. elles ne sont pas format�es comme la sortie de traces mais elles contiennent exactement la m�me information.
Lire un arbre de requ�te brut requiert un peu d'exp�rience. Mais comme les repr�sentations SQL des arbres de requ�tes sont suffisantes pour comprendre le syst�me de r�gles, ce chapitre ne vous apprendra pas � les lire.
Lors de la lecture des repr�sentations SQL 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
C'est une simple valeur indiquant quelle commande (select, insert, update, delete) l'arbre de requ�tes produira.
La table d'�chelle est une liste des relations utilis�es dans la requ�te. Dans une instruction select, ce sont les relations donn�es apr�s le mot cl� from.
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 SQL. 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.
C'est un index dans la table d'�chelle qui identifie la relation o� iront les r�sultats de la requ�te.
Les requ�tes select n'ont pas de relation r�sultat. Le cas sp�cial d'un select into est pratiquement identique � un create table suivi par un insert ... select et n'est pas discut� s�par�ment ici.
Pour les commandes insert, update et delete, la relation de r�sultat est la table (ou vue !) o� les changements prennent effet.
La liste cible est une liste d'expressions d�finissant le r�sultat d'une requ�te. Dans le cas d'un select, ces expressions sont celles qui construisent la sortie finale de la requ�te. Ils correspondent aux expressions entre les mots cl�s select et from (* 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).
Les commandes delete n'ont pas besoin d'une liste normale de colonnes car elles ne produisent aucun r�sultat. En fait, le syst�me de r�gles ajoutera une entr�e sp�ciale ctid pour aller jusqu'� la liste de cibles vide pour permettre � l'ex�cuteur de trouver la ligne � supprimer. (CTID est ajout� quand la relation r�sultante est une table ordinaire. S'il s'agit d'une vue, une variable de type ligne est ajout�e � la place, comme d�crit dans Section 37.2.4, � Mise � jour d'une vue �.)
Pour les commandes insert, la liste cible d�crit les nouvelles lignes devant aller dans la relation r�sultat. Elle consiste en des expressions de la clause values ou en celles de la clause select dans insert ... SELECT. 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.
Pour les commandes update, 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 set colonne = expression 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. Comme pour DELETE, le syst�me de r�gles ajoute un CTID ou une variable de type ligne pour que l'ex�cuteur puisse identifier l'ancienne ligne � mettre � jour.
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.
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 (insert, update, delete ou select) pour la ligne de r�sultat final devrait �tre ex�cut�e ou non. Elle correspond � la clause where d'une instruction SQL.
L'arbre de jointure de la requ�te affiche la structure de la clause from. pour une simple requ�te comme select ... from a, b, c, l'arbre de jointure est une simple liste d'�l�ments de from parce que nous sommes autoris�s � les joindre dans tout ordre. Mais quand des expressions join, 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 join. les restrictions associ�es avec ces clauses join particuli�res (� partir d'expressions on ou using) sont enregistr�es comme des expressions de qualification attach�es aux nœuds de l'arbre de jointure. Il s'av�re agr�able d'enregistrer l'expression de haut niveau where 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 from et where d'un select.
Les autres parties de l'arbre de requ�te comme la clause order BY 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.
Un exemple complet de trigger
