RPK wrote: > > I agree that TimeStamp creates an overhead, but I just want to know if an > accidental update happened to a table and this incident got traced three > days after, what facility PGSQL provide to bring the table to its original > condition. You can't wait regretting on why you did not run ROLLBACK > before > COMMIT. (Correct me. I am only a user). >
Why the heck can't you create a reversing transaction? That's what ordinary mortals do. Demanding unlimited undo at some time that is arbitrarilly distant in the future strikes me as wholly unreasonable. What do you mean by "accidental update"? What you really appear to mean is that a program or a human operator has made an error, and incorrectly told the database to commit a transaction. The answer surely is to correct the behaviour of the program or human, rather than wanting the database to provide an undo facility. Alternatively, this should be handled at the application layer, using something like table_log. Some things just don't work well with this sort of facility. Just ask your bookie if you can undo a bet that you "accidentally" placed with him and which, three days later, you discover (after the race) was a mistake. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly