mirror of https://github.com/postgres/postgres
Tom Lane
18 years ago
parent
53ae7acbba
commit
531f58688a
@ -1,104 +0,0 @@ |
||||
|
||||
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). |
||||
@ -1,116 +0,0 @@ |
||||
2. timetravel.c - functions for implementing time travel feature. |
||||
|
||||
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
||||
I rewritten this, because: |
||||
|
||||
on original version of postgresql 7.3.2-7.3.3: |
||||
|
||||
the UPDATE not work on timetravel.example if I added |
||||
>create unique index tttest_idx on tttest (price_id,price_off); |
||||
>update tttest set price_val = 30 where price_id = 3; |
||||
ERROR: Cannot insert a duplicate key into unique index tttest_idx |
||||
|
||||
And UPDATE not work on table tttest after |
||||
>alter table tttest add column q1 text; |
||||
>alter table tttest add column q2 int; |
||||
>alter table tttest drop column q1; |
||||
>update tttest set price_val = 30 where price_id = 3; |
||||
ERROR: Parameter '$5' is out of range |
||||
|
||||
And I add a new optional feature: my new timetravel have +3 optional parameters: |
||||
inserter_user, updater_user, deleter_user. |
||||
|
||||
And I add a new function: get_timetravel for get timetravel status |
||||
without change it. |
||||
|
||||
A big difference: |
||||
the old version on UPDATE changed oid on active ('infinity') record, |
||||
the new version UPDATE keep oid, and the overdued record have a new oid. |
||||
I sign with '!!!' my comment in this file. |
||||
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
||||
|
||||
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' |
||||
... ... |
||||
/* !!! and (if have) */ |
||||
ins_user text /* user, who insert this record */ |
||||
upd_user text /* user, who updated this record */ |
||||
del_user text /* user, who deleted this record */ |
||||
... ... |
||||
); |
||||
|
||||
!!! on INSERT my new version: |
||||
... and optionally set ins_user to current user, upd_user and del_user to null. |
||||
|
||||
- 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: |
||||
original version was: |
||||
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. |
||||
On my new version: |
||||
insert a new tuple with old values, but stop_date changed to current date; |
||||
and update original tuple with new data, and update start_date to current date |
||||
and optionally set upd_user to current user and clear ins_user,del_user. |
||||
|
||||
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). |
||||
On my new version: |
||||
... and optionally set del_user to current user. |
||||
|
||||
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. |
||||
Or add +3 arguments: |
||||
name of insert_user column, name of update_user column, name of delete_user column |
||||
|
||||
currabstime() may be used in DEFAULT for start_date column to get |
||||
current date. |
||||
!!! I deleted this function, because I newer used this. |
||||
|
||||
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. |
||||
|
||||
get_timetravel() reports time-travel status ON(1)/OFF(0) for a table. |
||||
get_timetravel() and set_timetravel() not checking existing of table and |
||||
existing of timetravel trigger on specified table. |
||||
|
||||
There is example in timetravel.example. |
||||
|
||||
To CREATE FUNCTIONs use timetravel.sql (will be made by gmake from |
||||
timetravel.source). |
||||
@ -1,52 +0,0 @@ |
||||
Example parser |
||||
============== |
||||
|
||||
This is an example of a custom parser for full text search. |
||||
|
||||
It recognizes space-delimited words and returns only two token types: |
||||
|
||||
- 3, word, Word |
||||
|
||||
- 12, blank, Space symbols |
||||
|
||||
The token numbers have been chosen to keep compatibility with the default |
||||
ts_headline() function, since we do not want to implement our own version. |
||||
|
||||
* Configuration |
||||
|
||||
The parser has no user-configurable parameters. |
||||
|
||||
* Usage |
||||
|
||||
1. Compile and install |
||||
|
||||
2. Load dictionary |
||||
|
||||
psql mydb < test_parser.sql |
||||
|
||||
3. Test it |
||||
|
||||
mydb# SELECT * FROM ts_parse('testparser','That''s my first own parser'); |
||||
tokid | token |
||||
-------+-------- |
||||
3 | That's |
||||
12 | |
||||
3 | my |
||||
12 | |
||||
3 | first |
||||
12 | |
||||
3 | own |
||||
12 | |
||||
3 | parser |
||||
|
||||
mydb# SELECT to_tsvector('testcfg','That''s my first own parser'); |
||||
to_tsvector |
||||
------------------------------------------------- |
||||
'my':2 'own':4 'first':3 'parser':5 'that''s':1 |
||||
|
||||
mydb# SELECT ts_headline('testcfg','Supernovae stars are the brightest phenomena in galaxies', to_tsquery('testcfg', 'star')); |
||||
headline |
||||
----------------------------------------------------------------- |
||||
Supernovae <b>stars</b> are the brightest phenomena in galaxies |
||||
|
||||
That's all. |
||||
Loading…
Reference in new issue