mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-20 03:43:22 +02:00
Install compiled functions into $(LIBDIR)/contrib. (Thanks to Brook Milligan <brook@trillium.NMSU.Edu>)
138 lines
5.3 KiB
Plaintext
138 lines
5.3 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 have to create trigger (BEFORE INSERT OR UPDATE) using this
|
|
function on a table referencing another table. You have 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 have to create trigger (BEFORE DELETE OR UPDATE) using this
|
|
function on a table referenced by another table(s). You have 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 have 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,
|
|
date_off abstime
|
|
... ...
|
|
);
|
|
|
|
CREATE TRIGGER timetravel
|
|
BEFORE INSERT OR DELETE OR UPDATE ON tttest
|
|
FOR EACH ROW
|
|
EXECUTE PROCEDURE
|
|
timetravel (date_on, date_off);
|
|
|
|
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 have 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 have to create trigger BEFORE (!!!) INSERT OR UPDATE OR DELETE using
|
|
this function on a time-traveled table. You have to specify two arguments:
|
|
name of start_date column and name of stop_date column in triggered table.
|
|
|
|
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).
|
|
|
|
|
|
3. autoinc.c - function for implementing AUTOINCREMENT/IDENTITY feature.
|
|
|
|
You have to create BEFORE INSERT OR UPDATE trigger using function
|
|
autoinc(). You have to specify as function arguments: column name
|
|
(of int4 type) for which you want to get this feature and name of
|
|
SEQUENCE from which next value has to be fetched when NULL or 0
|
|
value is being inserted into column (, ... - you are able to specify
|
|
as many column/sequence pairs as you need).
|
|
|
|
There is example in autoinc.example.
|
|
|
|
To CREATE FUNCTION use autoinc.sql (will be made by gmake from
|
|
autoinc.source).
|
|
|
|
|
|
4. insert_username.c - function for inserting user names.
|
|
|
|
You have to create BEFORE INSERT OR UPDATE trigger using the function
|
|
insert_username(). You have to specify as a function argument: the column
|
|
name (of text type) in which user names will be inserted. Note that user
|
|
names will be inserted irregardless of the initial value of the field, so
|
|
that users cannot bypass this functionality by simply defining the field to
|
|
be NOT NULL.
|
|
|
|
There is an example in insert_username.example.
|
|
|
|
To CREATE FUNCTION use insert_username.sql (will be made by gmake from
|
|
insert_username.source).
|