Skip to content

P
Postgres FD Implementation
Commit 2d10defa authored by Andres Freund's avatar Andres Freund
Browse files
Options

Remove timetravel extension. 

The extension depended on old types which are about to be removed. As
the code additionally was pretty crufty and didn't provide much in the
way of functionality, removing the extension seems to be the best way
forward.  It's fairly trivial to write functionality in plpgsql that
more than covers what timetravel did.

Author: Andres Freund
Discussion:
    https://postgr.es/m/20171213080506.cwjkpcz3bkk6yz2u@alap3.anarazel.de
    https://postgr.es/m/25615.1513115237@sss.pgh.pa.us
parent 86896be6
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 4 additions and 764 deletions
contrib/spi/Makefile
View file @ 2d10defa
# contrib/spi/Makefile
MODULES = autoinc insert_username moddatetime refint timetravel
MODULES = autoinc insert_username moddatetime refint
EXTENSION = autoinc insert_username moddatetime refint timetravel
EXTENSION = autoinc insert_username moddatetime refint
DATA = autoinc--1.0.sql autoinc--unpackaged--1.0.sql \
insert_username--1.0.sql insert_username--unpackaged--1.0.sql \
moddatetime--1.0.sql moddatetime--unpackaged--1.0.sql \
refint--1.0.sql refint--unpackaged--1.0.sql \
timetravel--1.0.sql timetravel--unpackaged--1.0.sql
refint--1.0.sql refint--unpackaged--1.0.sql
PGFILEDESC = "spi - examples of using SPI and triggers"
DOCS = $(addsuffix .example, $(MODULES))
......
contrib/spi/timetravel--1.0.sql deleted 100644 → 0
View file @ 86896be6
/* contrib/spi/timetravel--1.0.sql */
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION timetravel" to load this file. \quit
CREATE FUNCTION timetravel()
RETURNS trigger
AS 'MODULE_PATHNAME'
LANGUAGE C;
CREATE FUNCTION set_timetravel(name, int4)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE C RETURNS NULL ON NULL INPUT;
CREATE FUNCTION get_timetravel(name)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE C RETURNS NULL ON NULL INPUT;
contrib/spi/timetravel--unpackaged--1.0.sql deleted 100644 → 0
View file @ 86896be6
/* contrib/spi/timetravel--unpackaged--1.0.sql */
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION timetravel FROM unpackaged" to load this file. \quit
ALTER EXTENSION timetravel ADD function timetravel();
ALTER EXTENSION timetravel ADD function set_timetravel(name,integer);
ALTER EXTENSION timetravel ADD function get_timetravel(name);
contrib/spi/timetravel.c deleted 100644 → 0
View file @ 86896be6
This diff is collapsed.
contrib/spi/timetravel.control deleted 100644 → 0
View file @ 86896be6
# timetravel extension
comment = 'functions for implementing time travel'
default_version = '1.0'
module_pathname = '$libdir/timetravel'
relocatable = true
contrib/spi/timetravel.example deleted 100644 → 0
View file @ 86896be6
drop table tttest;
create table tttest (
price_id int4,
price_val int4,
price_on abstime,
price_off abstime
);
create unique index tttest_idx on tttest (price_id,price_off);
alter table tttest add column q1 text;
alter table tttest add column q2 int;
alter table tttest drop column q1;
create trigger timetravel
before insert or delete or update on tttest
for each row
execute procedure
timetravel (price_on, price_off);
insert into tttest values (1, 1, null, null);
insert into tttest(price_id, price_val) values (2, 2);
insert into tttest(price_id, price_val,price_off) values (3, 3, 'infinity');
insert into tttest(price_id, price_val,price_off) values (4, 4,
abstime('now'::timestamp - '100 days'::interval));
insert into tttest(price_id, price_val,price_on) values (3, 3, 'infinity'); -- duplicate key
select * from tttest;
delete from tttest where price_id = 2;
select * from tttest;
-- what do we see ?
-- get current prices
select * from tttest where price_off = 'infinity';
-- change price for price_id == 3
update tttest set price_val = 30 where price_id = 3;
select * from tttest;
-- now we want to change price_id from 3 to 5 in ALL tuples
-- but this gets us not what we need
update tttest set price_id = 5 where price_id = 3;
select * from tttest;
-- restore data as before last update:
select set_timetravel('tttest', 0); -- turn TT OFF!
select get_timetravel('tttest'); -- check status
delete from tttest where price_id = 5;
update tttest set price_off = 'infinity' where price_val = 30;
select * from tttest;
-- and try change price_id now!
update tttest set price_id = 5 where price_id = 3;
select * from tttest;
-- isn't it what we need ?
select set_timetravel('tttest', 1); -- turn TT ON!
select get_timetravel('tttest'); -- check status
-- we want to correct some date
update tttest set price_on = 'Jan-01-1990 00:00:01' where price_id = 5 and
price_off <> 'infinity';
-- but this doesn't work
-- try in this way
select set_timetravel('tttest', 0); -- turn TT OFF!
select get_timetravel('tttest'); -- check status
update tttest set price_on = '01-Jan-1990 00:00:01' where price_id = 5 and
price_off <> 'infinity';
select * from tttest;
-- isn't it what we need ?
-- get price for price_id == 5 as it was '10-Jan-1990'
select * from tttest where price_id = 5 and
price_on <= '10-Jan-1990' and price_off > '10-Jan-1990';
doc/src/sgml/contrib-spi.sgml
View file @ 2d10defa
......@@ -65,99 +65,6 @@
</para>
</sect2>
<sect2>
<title>timetravel &mdash; 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 &mdash; 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 &mdash; 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 &mdash; Functions for Autoincrementing Fields</title>
......
src/tools/msvc/Install.pm
View file @ 2d10defa
......@@ -605,7 +605,7 @@ sub CopySubdirFiles
# Special case for contrib/spi
$flist =
"autoinc.example insert_username.example moddatetime.example refint.example timetravel.example"
"autoinc.example insert_username.example moddatetime.example refint.example"
if ($module eq 'spi');
foreach my $f (split /\s+/, $flist)
{
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment