Hi

> Or else, what might be good would be something like a shadow 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...

This seems even theoretically impossible to me: What happens, when you have
a trigger, creating a record in one table when deleteing a record in
another?
If you restore that record "from outside", will you also remove the record
created by the trigger? What if this invokes another trigger......

So this is not implementable as a generall approc
h.
BUT everyone who really needs this, CAN DO THIS, have a trigger as:
1. Have a second table.
2. For the main table, insert a trigger that creates a record on the second
table upon deleting a record in the main table.
3. Revoke access to the second table for the connecting user.

Then the user *CAN* do "delete from maintable" without problems. :D

This approch, done "manually", can respect application logic and can
therefor do better than the rdbms could.

Regards,
Steffen