diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/contrib-spi.sgml | 93 |
1 files changed, 0 insertions, 93 deletions
diff --git a/doc/src/sgml/contrib-spi.sgml b/doc/src/sgml/contrib-spi.sgml index 844ea161c42..fed6f249328 100644 --- a/doc/src/sgml/contrib-spi.sgml +++ b/doc/src/sgml/contrib-spi.sgml @@ -66,99 +66,6 @@ </sect2> <sect2> - <title>timetravel — Functions for Implementing Time Travel</title> - - <para> - Long ago, <productname>PostgreSQL</productname> had a built-in time travel feature - that kept the insert and delete times for each tuple. This can be - emulated using these functions. To use these functions, - you must add to a table two columns of <type>abstime</type> type to store - the date when a tuple was inserted (start_date) and changed/deleted - (stop_date): - -<programlisting> -CREATE TABLE mytab ( - ... ... - start_date abstime, - stop_date abstime - ... ... -); -</programlisting> - - The columns can be named whatever you like, but in this discussion - we'll call them start_date and stop_date. - </para> - - <para> - When a new row is inserted, start_date should normally be set to - current time, and stop_date to <literal>infinity</literal>. The trigger - will automatically substitute these values if the inserted data - contains nulls in these columns. Generally, inserting explicit - non-null data in these columns should only be done when re-loading - dumped data. - </para> - - <para> - Tuples with stop_date equal to <literal>infinity</literal> are <quote>valid - now</quote>, and can be modified. Tuples with a finite stop_date cannot - be modified anymore — the trigger will prevent it. (If you need - to do that, you can turn off time travel as shown below.) - </para> - - <para> - For a modifiable row, on update only the stop_date in the tuple being - updated will be changed (to current time) and a new tuple with the modified - data will be inserted. Start_date in this new tuple will be set to current - time and stop_date to <literal>infinity</literal>. - </para> - - <para> - A delete does not actually remove the tuple but only sets its stop_date - to current time. - </para> - - <para> - To query for tuples <quote>valid now</quote>, include - <literal>stop_date = 'infinity'</literal> in the query's WHERE condition. - (You might wish to incorporate that in a view.) Similarly, you can - query for tuples valid at any past time with suitable conditions on - start_date and stop_date. - </para> - - <para> - <function>timetravel()</function> is the general trigger function that supports - this behavior. Create a <literal>BEFORE INSERT OR UPDATE OR DELETE</literal> - trigger using this function on each time-traveled table. Specify two - trigger arguments: the actual - names of the start_date and stop_date columns. - Optionally, you can specify one to three more arguments, which must refer - to columns of type <type>text</type>. The trigger will store the name of - the current user into the first of these columns during INSERT, the - second column during UPDATE, and the third during DELETE. - </para> - - <para> - <function>set_timetravel()</function> allows you to turn time-travel on or off for - a table. - <literal>set_timetravel('mytab', 1)</literal> will turn TT ON for table <literal>mytab</literal>. - <literal>set_timetravel('mytab', 0)</literal> will turn TT OFF for table <literal>mytab</literal>. - In both cases the old status is reported. While TT is off, you can modify - the start_date and stop_date columns freely. Note that the on/off status - is local to the current database session — fresh sessions will - always start out with TT ON for all tables. - </para> - - <para> - <function>get_timetravel()</function> returns the TT state for a table without - changing it. - </para> - - <para> - There is an example in <filename>timetravel.example</filename>. - </para> - </sect2> - - <sect2> <title>autoinc — Functions for Autoincrementing Fields</title> <para> |