524cfad23f
the new timetravel.c,
new timetravel.README (cut from spi/README and modified),
modified timetravel.sql.in
and modified timetravel.example.
Features:
- optionally 3 parameter for insert/update/delete user name
- work with CREATE UNIQUE INDEX ixxx on table xxx
(unique_field,time_off);
(the original version was work with unique index on 6.5.0-6.5.3,
and not work on 7.3.2,7.3.3)
(before 6.5.0 and between 6.5.3 and 7.3.2 I dont know)
- get_timetravel(tablename) function for check timetravel-status.
- timetravel trigger not change oid of the active record. (it is not a
good feature, because the old version is automatice prevent the paralel
update with "where oid=nnn")
B?jthe Zolt?n
116 lines
4.4 KiB
Text
116 lines
4.4 KiB
Text
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).
|