Los sistemas de reglas de producci�n son conceptualmente simples, pero hay muchos puntos sutiles implicados en el uso actual de ellos. Algunos de estos puntos y los fundamentos te�ricos del sistema de reglas de Postgres se pueden encontrar en [Stonebraker et al, ACM, 1990].
Algunos otros sistemas de base de datos definen reglas de base de datos activas. �stas son habitualmente procedimientos y disparadores (a partir de aqu� utilizar� el t�rmino m�s habitual de "trigger") almacenados y se implementan en Postgres como funciones y triggers.
El sistema de reglas de reescritura de queries (el "sistema de reglas" a partir de ahora) es totalmente diferente a los procedimientos almacenados y los triggers. �l modifica las queries para tomar en consideraci�n las reglas y entonces pasa la query modificada al optimizador para su ejecuci�n. Es muy poderoso, y puede utilizarse de muchas formas, tales como procedimientos, vistas y versiones del lenguaje de query. El poder de este sistema de reglas se discute en [Ong and Goh, 1990] y en [Stonebraker et al, ACM, 1990].
Para comprender como trabaja el sistema de reglas, es necesario conocer cu�ndo se invoca y cu�les son sus inputs y sus resultados.
El sistema de reglas se situa entre el traductor de la query y el optimizador. Toma la salida del traductor, un �rbol de la query, y las reglas de reescritura del cat�logo pg_rewrite, los cuales son tambi�n �rboles de queries con alguna informaci�n extra, y crea cero o muchos �rboles de query como resultado. De este modo, su input y su output son siempre tales como el traductor mismo podr�a haberlos producido y, de este modo, todo aparece b�sicamente repesentable como una instrucci�n SQL.
Ahora, �qu� es un �rbol de query? Es una representaci�n interna de una instrucci�n SQL donde se almacenan de modo separado las partes menores que la componen. Estos �rboles de query son visibles cuando arrancamos el motor de Postgres con nivel de debug 4 y tecleamos queries en el interface de usuario interactivo. Las acciones de las reglas almacenadas en el catalgo de sistema pg_rewrite est�n almacenadas tambi�n como �rboles de queries. No est�n formateadas como la salida del debug, pero contienen exactamente la misma informaci�n.
Leer un �rbol de query requiere experiencia y era bastante duro cuando empec� a trabajar en el sistema de reglas. Puedo recordar que mientras estaba esperando en la m�quina de caf� asimilaba el vaso a una lista de objetivos, el agua y el polvo del caf� a una tabla de rangos, y todos los botones a expresiones de cualificaci�n. Puesto que las representaciones de SQL de �rboles de queries son suficientes para entender el sistema de reglas, este documento no le ense�ar� como leerlo. �l deber�a ayudarle a aprenderlo, con las convenciones de nombres requeridas en las descripciones que siguen m�s adelante.
Cuando se leen las representaciones de SQL de los �rboles de queries en este documento, es necesario ser capaz de identificar las partes de la instrucci�n que se ha roto en ella, y que est� en la estructura del �rbol de query. Las partes de un �rbol de query son:
Este es un valor sencillo que nos dice el comando que produjo el arbol de traducci�n (SELECT, INSERT, UPDATE, DELETE).
La tabla de rango es una lista de las relaciones que se utilizan en la query. En una instrucci�n SELECT, son las relaciones dadas tras la palabra clave FROM.
Toda entrada en la tabla del rango identifica una tabla o vista, y nos dice el nombre por el que se la identifica en las otras partes de la query. En un �rbol de query, las entradas de la tabla de rango se indican por un �ndice en lugar de por su nombre como estar�an en una instrucci�n SQL. Esto puede ocurrir cuando se han mezclado las tablas de rangos de reglas. Los ejemplos de este documento no muestran esa situaci�n.
Un �ndice a la tabla de rango que identifica la relaci�n donde ir�n los resultados de la query.
Las queries SELECT normalmente no tienen una relaci�n resultado. El caso especial de una SELECT INTO es principalmente identica a una secuencia CREATE TABLE, INSERT ... SELECT y no se discute aqu� por separado.
En las queries INSERT, UPDATE y DELETE, la relaci�n resultado es la tabla (�o vista!) donde tendr�n efecto los cambios.
La lista objetivo es una lista de expresiones que definen el resultado de la query. En el caso de una SELECT, las expresiones son las que construyen la salida final de la query. Son las expresiones entre las palabras clave SELECT y FROM (* es s�lo una abreviatura de todos los nombres de atributos de una relaci�n).
Las queries DELETE no necesitan una lista objetivo porque no producen ning�n resultado. De hecho, el optimizador a�adir� una entrada especial para una lista objetivo vac�a. Pero esto ocurre tras el sistema de reglas y lo comentaremos m�s tarde. Para el sistema de reglas, la lista objetivo est� vac�a.
En queries INSERT la lista objetivo describe las nuevas filas que ir�n a la relaci�n resultado. Las columnas que no aparecen en la relaci�n resultado ser�n a�adidas por el optimizador con una expresi�n constante NULL. Son las expresiones de la clausula VALUES y las de la clausula SELECT en una INSERT .... SELECT.
En queries UPDATE, describe las nuevas filas que reemplazar�n a otras viejas. Ahora el optimizador a�adir� las columnas que no aparecen insertando expresiones que recuperan los valores de las filas viejas en las nuevas. Y a�adir� una entrada especial como lo hace DELETE. Es la parte de la query que recoge las expresiones del atributo SET atributo = expresi�n.
Cada entrada de la lista objetivo contiene una expresion que puede ser un valor constante, una variable apuntando a un atributo de una de las relaciones en la tabla de rango, un par�metro o un arbol de expresiones hecho de llamadas a funciones, constantes, variables, operadores, etc.
La cualificaci�n de las queries es una expresi�n muy similar a otra de las contenidas en las entradas de la lista objetivo. El valor resultado de esta expresi�n e un booleano que dice si la operaci�n (INSERT, UPDATE, DELETE o SELECT) para las filas del resultado final deber� ser ejecutada o no. Es la clausula WHERE de una instrucci�n SQL.
Las otras partes de un arbol de query, como la clausula ORDER BY, no tienen inter�s aqu�. El sistema de reglas sustituye las entradas aqu� presentes mientras est� aplicando las reglas, pero aquellas no tiene mucho que hacer con los fundamentos del sistema de reglas. GROUP BY es una forma especial en la que aparece una definici�n de una vista, y a�n necesita ser documentado.