head	1.2;
access;
symbols
	REL7_4_29:1.1
	REL8_0_25:1.1
	REL8_1_21:1.1
	REL8_2_17:1.1
	REL7_4_28:1.1
	REL8_0_24:1.1
	REL8_1_20:1.1
	REL8_2_16:1.1
	REL7_4_27:1.1
	REL8_0_23:1.1
	REL8_1_19:1.1
	REL8_2_15:1.1
	REL7_4_26:1.1
	REL8_0_22:1.1
	REL8_1_18:1.1
	REL8_2_14:1.1
	REL7_4_25:1.1
	REL8_0_21:1.1
	REL8_1_17:1.1
	REL8_2_13:1.1
	REL7_4_24:1.1
	REL8_0_20:1.1
	REL8_1_16:1.1
	REL8_2_12:1.1
	REL7_4_23:1.1
	REL8_0_19:1.1
	REL8_1_15:1.1
	REL8_2_11:1.1
	REL7_4_22:1.1
	REL8_0_18:1.1
	REL8_1_14:1.1
	REL8_2_10:1.1
	REL7_4_21:1.1
	REL8_0_17:1.1
	REL8_1_13:1.1
	REL8_2_9:1.1
	REL7_4_20:1.1
	REL8_0_16:1.1
	REL8_1_12:1.1
	REL8_2_8:1.1
	REL8_2_7:1.1
	REL7_4_19:1.1
	REL8_0_15:1.1
	REL8_1_11:1.1
	REL8_2_6:1.1
	REL8_3_BETA4:1.1
	REL8_3_BETA3:1.1
	REL8_3_BETA2:1.1
	REL8_3_BETA1:1.1
	REL7_4_18:1.1
	REL8_0_14:1.1
	REL8_1_10:1.1
	REL8_2_5:1.1
	REL7_4_17:1.1
	REL8_0_13:1.1
	REL8_1_9:1.1
	REL8_2_4:1.1
	REL8_0_12:1.1
	REL8_1_8:1.1
	REL8_2_3:1.1
	REL7_4_16:1.1
	REL8_0_11:1.1
	REL8_1_7:1.1
	REL8_2_2:1.1
	REL8_0_10:1.1
	REL8_1_6:1.1
	REL8_2_1:1.1
	REL7_4_15:1.1
	REL8_2_STABLE:1.1.0.12
	REL8_2_0:1.1
	REL8_2_RC1:1.1
	REL8_2_BETA3:1.1
	REL8_2_BETA2:1.1
	REL8_1_5:1.1
	REL8_0_9:1.1
	REL7_4_14:1.1
	REL8_2_BETA1:1.1
	REL7_4_13:1.1
	REL8_0_8:1.1
	REL8_1_4:1.1
	REL7_4_12:1.1
	REL8_0_7:1.1
	REL8_1_3:1.1
	REL7_4_11:1.1
	REL8_0_6:1.1
	REL8_1_2:1.1
	REL7_4_10:1.1
	REL8_0_5:1.1
	REL8_1_1:1.1
	REL8_1_STABLE:1.1.0.10
	REL8_1_0:1.1
	REL8_1_0RC1:1.1
	REL8_1_0BETA4:1.1
	REL8_1_0BETA3:1.1
	REL7_4_9:1.1
	REL8_0_4:1.1
	REL8_1_0BETA2:1.1
	REL8_1_0BETA1:1.1
	REL7_4_8:1.1
	REL8_0_3:1.1
	REL8_0_2:1.1
	REL7_4_7:1.1
	REL8_0_1:1.1
	REL8_0_STABLE:1.1.0.8
	REL8_0_0:1.1.0.6
	REL8_0_0RC5:1.1
	REL8_0_0RC4:1.1
	REL8_0_0RC3:1.1
	REL8_0_0RC2:1.1
	REL8_0_0RC1:1.1
	REL8_0_0BETA5:1.1
	REL8_0_0BETA4:1.1
	REL7_4_6:1.1
	REL8_0_0BETA3:1.1
	REL8_0_0BETA2:1.1
	REL7_4_5:1.1
	REL7_4_4:1.1
	REL8_0_0BETA1:1.1
	REL7_4_3:1.1
	REL7_4_2:1.1
	REL7_4_1:1.1
	REL7_4:1.1
	REL7_4_RC2:1.1
	REL7_4_STABLE:1.1.0.4
	REL7_4_RC1:1.1
	REL7_4_BETA5:1.1
	REL7_4_BETA4:1.1
	REL7_4_BETA3:1.1
	REL7_4_BETA2:1.1
	WIN32_DEV:1.1.0.2
	REL7_4_BETA1:1.1;
locks; strict;
comment	@# @;


1.2
date	2007.12.03.04.22.54;	author tgl;	state dead;
branches;
next	1.1;

1.1
date	2003.07.27.04.51.45;	author momjian;	state Exp;
branches;
next	;


desc
@@


1.2
log
@Remove obsoleted README files.
@
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).
@


1.1
log
@Here is 4 file in tgz:
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
@
text
@@

