mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-30 00:04:49 -04:00 
			
		
		
		
	
		
			
				
	
	
		
			105 lines
		
	
	
		
			4.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			105 lines
		
	
	
		
			4.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
 | |
| Here are general trigger functions provided as workable examples
 | |
| of using SPI and triggers. "General" means that functions may be
 | |
| used for defining triggers for any tables but you have to specify
 | |
| table/field names (as described below) while creating a trigger.
 | |
| 
 | |
| 1. refint.c - functions for implementing referential integrity.
 | |
| 
 | |
| check_primary_key () is to used for foreign keys of a table.
 | |
|    
 | |
|    You are to create trigger (BEFORE INSERT OR UPDATE) using this 
 | |
| function on a table referencing another table. You are to specify
 | |
| as function arguments: triggered table column names which correspond
 | |
| to foreign key, referenced table name and column names in referenced
 | |
| table which correspond to primary/unique key.
 | |
|    You may create as many triggers as you need - one trigger for
 | |
| one reference.
 | |
| 
 | |
| check_foreign_key () is to used for primary/unique keys of a table.
 | |
| 
 | |
|    You are to create trigger (BEFORE DELETE OR UPDATE) using this
 | |
| function on a table referenced by another table(s). You are to specify
 | |
| as function arguments: number of references for which function has to
 | |
| performe checking, action if referencing key found ('cascade' - to delete
 | |
| corresponding foreign key, 'restrict' - to abort transaction if foreign keys 
 | |
| exist, 'setnull' - to set foreign key referencing primary/unique key
 | |
| being deleted to null), triggered table column names which correspond
 | |
| to primary/unique key, referencing table name and column names corresponding
 | |
| to foreign key (, ... - as many referencing tables/keys as specified
 | |
| by first argument).
 | |
|    Note, that NOT NULL constraint and unique index have to be defined by
 | |
| youself.
 | |
| 
 | |
|    There are examples in refint.example and regression tests
 | |
| (sql/triggers.sql).
 | |
| 
 | |
|    To CREATE FUNCTIONs use refint.sql (will be made by gmake from
 | |
| refint.source).
 | |
| 
 | |
| 
 | |
| 2. timetravel.c - functions for implementing time travel feature.
 | |
| 
 | |
|    Old internally supported time-travel (TT) used insert/delete
 | |
| transaction commit times. To get the same feature using triggers
 | |
| you are to add to a table two columns of abstime type to store
 | |
| date when a tuple was inserted (start_date) and changed/deleted 
 | |
| (stop_date):
 | |
| 
 | |
| CREATE TABLE XXX (
 | |
| 	...		...
 | |
| 	date_on		abstime default currabstime(),
 | |
| 	date_off	abstime default 'infinity'
 | |
| 	...		...
 | |
| );
 | |
| 
 | |
| - so, tuples being inserted with NULLs in date_on/date_off will get
 | |
| _current_date_ in date_on (name of start_date column in XXX) and INFINITY in
 | |
| date_off (name of stop_date column in XXX).
 | |
| 
 | |
|    Tuples with stop_date equal INFINITY are "valid now": when trigger will
 | |
| be fired for UPDATE/DELETE of a tuple with stop_date NOT equal INFINITY then
 | |
| this tuple will not be changed/deleted!
 | |
| 
 | |
|    If stop_date equal INFINITY then on
 | |
| 
 | |
| UPDATE: only stop_date in tuple being updated will be changed to current
 | |
| date and new tuple with new data (coming from SET ... in UPDATE) will be
 | |
| inserted. Start_date in this new tuple will be setted to current date and
 | |
| stop_date - to INFINITY.
 | |
| 
 | |
| DELETE: new tuple will be inserted with stop_date setted to current date
 | |
| (and with the same data in other columns as in tuple being deleted).
 | |
| 
 | |
|    NOTE:
 | |
| 1. To get tuples "valid now" you are to add _stop_date_ = 'infinity'
 | |
|    to WHERE. Internally supported TT allowed to avoid this...
 | |
|    Fixed rewriting RULEs could help here...
 | |
|    As work arround you may use VIEWs...
 | |
| 2. You can't change start/stop date columns with UPDATE! 
 | |
|    Use set_timetravel (below) if you need in this.
 | |
| 
 | |
|    FUNCTIONs:
 | |
| 
 | |
| timetravel() is general trigger function.
 | |
| 
 | |
|    You are to create trigger BEFORE (!!!) UPDATE OR DELETE using this
 | |
| function on a time-traveled table. You are to specify two arguments: name of
 | |
| start_date column and name of stop_date column in triggered table.
 | |
| 
 | |
| currabstime() may be used in DEFAULT for start_date column to get
 | |
| current date.
 | |
| 
 | |
| set_timetravel() allows you turn time-travel ON/OFF for a table:
 | |
| 
 | |
|    set_timetravel('XXX', 1) will turn TT ON for table XXX (and report
 | |
| old status).
 | |
|    set_timetravel('XXX', 0) will turn TT OFF for table XXX (-"-).
 | |
| 
 | |
| Turning TT OFF allows you do with a table ALL what you want.
 | |
| 
 | |
|    There is example in timetravel.example.
 | |
| 
 | |
|    To CREATE FUNCTIONs use timetravel.sql (will be made by gmake from
 | |
| timetravel.source).
 |