Hi!

I have a feature request to make; if this is not the right place to do
so, please tell me where to go!

So here it is. Why not create a sort of "undo-after-commit" feature, whereby old versions of a record could be kept indefinitely, and if necessary, restored of viewed?

What might be good would be some sort of trace file, in
which, all obselete record versions are dumped, as and when they become
obselete. Then, there could be a simple API (or perhaps an SQL
extention) that could be used for loading old record versions back into
the DB, and also for purging out old versions periodically...

Of course, we can't make the restore process entirely
automatic, as that might make it unusable in complex cases.
Perhaps the best thing would be a syntax similar to the following :

CREATE TRACE (or some other name...) <NAME> [PARAMS];

SELECT <COLS> FROM <TRACE_NAME>(<TIMESTAMP>).<TABLE_NAME>;
INSERT INTO <TRACE_NAME>(<TIMESTAMP>).<TABLE_NAME> (<COLS>) VALUES
(<VALUES>);
ETC...

This sort of thing would be good. It's true that if we make things
completely automatic, it will be unasable. But if we simply make the
tables the backup contains accessible, based on a certain timestamp,
then after that, it could be manipulated as though it were an ordinary
part of the database, allowing you to be as flexible as you need to be.

This could use the same syntax as that which will be used if/when it
becomes possible to access an external database simultaneously (I think
I heard talk of this perhaps getting implemented one day). The backup
could be treated just as though it were an external database, except
that it would be read-only, and there would be no triggers nor procedures...


Jonathan Neve.