Cláusula de Constraint	Nombre de Constraint	Usos	Nombre de Índice/Trigger	Función de Trigger
PRIMARY KEY	table_pkey (p)	índice	table_pkey
UNIQUE	table_column_key (u)	índice	table_column_key
FOREIGN KEY	$n (f)	trigger	RI_ConstraintTrigger_n	RI_FKey_check_ins
tabla referida	$n (f)	trigger	RI_ConstraintTrigger_n	RI_FKey_noaction_del
tabla referida	$n (f)	trigger	RI_ConstraintTrigger_n	RI_FKey_noaction_upd
CHECK	table_column (c)	check	ninguno

References y Foreign Keys
Para los propósitos de estas descripciones, REFERENCES y FOREIGN KEYS (llaves foráneas) son intercambiables, puesto que tienen la misma implementación. Las referencias y llaves foráneas usan el mismo conjunto de funciones internas para hacer las verificaciones, cuyos nombres comienzan con RI_FKey_.

Una tabla que define una llave foránea también instala implícitamente triggers en update y delete en la tabla a la que se hace referencia. En el caso de arriba, el trigger implementa el comportamiento NO ACTION por omisión en las tablas a las que se hace referencia. Si la llave foránea se definiera con directivas diferentes, se instalaría una de las otras funciones. Estas son las funciones que se usan para las restricciones de integridad referencial:

Las restricciones de llaves foráneas tienen nombre del estilo $1, $2, etc. Los triggers tienen nombres que se construyen usando números basados en los OIDs.

Checks y otras restricciones
La restricción CHECK se almacena como una restricción específica del atributo: no es una función ni un índice. La expresión compilada de CHECK, junto con su código fuente, se almacenan en la tabla pg_constraint.

Los valores DEFAULT y las condiciones NOT NULL son, conceptualmente, restricciones, pero no son implementadas como otras restricciones, sino que son atributos de las columnas y se almacenan en las tablas pg_attributes y pg_attrdef.

Restricciones con Nombre
Los nombres por omisión de FOREIGN KEY, UNIQUE y CHECK pueden ser reemplazados. Para darle un nombre a una restricción, preceda su definición con CONSTRAINT nombre como se ilustra en el siguiente ejemplo.

	create table showconstraints (
	   id	integer PRIMARY KEY,
	   unq integer CONSTRAINT sc_unq UNIQUE,
	   checkme integer CONSTRAINT posval CHECK ( checkme > 0 )
	);

Consultas Informativas
A continuación presentamos algunas consultas para mostrar las restricciones en sus tablas. Para usar estas consultas, sustituya el nombre de la tabla en cuestión en cada una de las cláusulas WHERE, o use una función que reemplace el nombre de la tabla.

	-- ¿Qué índices tiene la tabla?
	select * from pg_indexes where tablename = 'tabla';
	
	-- ¿Qué triggers hay en la tabla?
	select c.relname as "Table", t.tgname as "Nombre de Trigger", 
	   t.tgconstrname as "Nombre de Restricción", t.tgenabled as "Activado",
	   t.tgisconstraint as "Es Restricción", cc.relname as "Tabla Referida",
	   p.proname as "Nombre de Función"
	from pg_trigger t, pg_class c, pg_class cc, pg_proc p
	where t.tgfoid = p.oid and t.tgrelid = c.oid
	   and t.tgconstrrelid = cc.oid
	   and c.relname = 'tabla';
	
	-- ¿Qué restricciones hay en la tabla?
	select r.relname as "Tabla", c.conname as "Nombre de Restricción",
	   contype as "Tipo de Restricción", conkey as "Columnas de Llave",
	   confkey as "Columnas Referidas", consrc as "Fuente"
	from pg_class r, pg_constraint c
	where r.oid = c.conrelid
	   and relname = 'tabla';

Contribuyeron: Thomas LeBlanc thomasatiem at hotmail.com, Manfred Koizar mkoi-pg at aon.at, scott.marlowe scott.marlowe at ihs.com, elein at varlena.com

Este es un buen momento para mencionar que el formato de entrada de las fechas cambia entre las versiones 7.3 y 7.4. En 7.4, el formato de entrada de las fechas se controlará con el parámetro de configuracion datestyle, que puede ser definido en postgresql.conf o usando una sentencia SET en un guión SQL.

En 7.3 y anteriores, el servidor intentaba adivinar el formato de la fecha en la entrada basado en los valores. Esto llevaba a posibles datos erróneos cuando el formato era ambiguo. Por ejemplo, en la primera consulta del ejemplo de abajo, la fecha es interpretada como mes/día/año. En la segunda se interpreta como día/mes/año, debido a los valores. Es posible que alguna de las dos estuviera errónea, pero no lo sabría porque no genera errores.

   =# select date('01/10/03'),to_char( date('01/10/03'), 'dd-mon-yyyy');
       date    |   to_char
   ------------+-------------
    2003-01-10 | 10-jan-2003
   (1 row)

   =# select date('20/10/03'),to_char( date('20/10/03'), 'dd-mon-yyyy');
       date    |   to_char
   ------------+-------------
    2003-10-20 | 20-oct-2003
   (1 row)

	Postgres 7.3.3:
	
	test=# select '18/03/71'::date;
	    date
	------------
	 1971-03-18
	(1 row)
	
	
	Postgres 7.4head
	
	regression=# select '18/03/71'::date;
	ERROR:  invalid input syntax for date: "18/03/71"
	
	regression=# show DateStyle ;
	 DateStyle
	-----------
	 ISO, MDY
	(1 row)
	
	regression=# set datestyle = dmy;
	SET
	
	regression=# select '18/03/71'::date;
	    date
	------------
	 1971-03-18
	(1 row)

Contribuyeron: Mendola Gaetano mendola@bigfoot.com, Bruce Momjian pgman@candle.pha.pa.us, Tom Lane tgl@sss.pgh.pa.us, Andrew Dunstan andrew@dunslane.net, Kevin Brown kevin@sysexperts.com, Christopher Kings-Lynne chriskl@familyhealth.com.au, Dennis Björklund db@zigo.dhs.org, Scott Lamb slamb@slamb.org

Las funciones en pltcl pueden ser muy versátiles. La siguiente función es una función de trigger que muestra varias características particulares de pltcl.

Es una función de trigger genérica que puede forzar una o más columnas de una tabla a minúsculas. Puede ser usada en un trigger en una amplia variedad de tablas.

	create or replace function force_lower () returns trigger as '
	    foreach key $args {
	        if {[info exists NEW($key)]} {
	            set NEW($key) [string tolower $NEW($key)]
	        }
	    }
	    return [array get NEW]
	' language pltcl;
	
	create trigger force_lower before insert or update on mytable
	    for each row execute procedure force_lower('field_1', 'field_n');

Las características claves que esta función demuestra son que correctamente ignora valores NULL, que toma argumentos incluso siendo una función de trigger, y que el número de argumentos es variable.

Usando esta función y la definición de trigger como modelo, puede implementar casi cualquier clase de filtrado, formateo o cálculo en los valores de entrada para sus tablas.

Contribuyeron: Jules Alberts jules.alberts at arbodienst-limburg.nl, Robert Treat xzilla at users.sourceforge.net, darren at crystalballinc.com, Jan Wieck JanWieck at Yahoo.com