Re: New feature request: FlashBack Query - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: New feature request: FlashBack Query
Date
Msg-id 60087.24.211.165.134.1171975372.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: New feature request: FlashBack Query  (RPK <rohitprakash123@indiatimes.com>)
Responses Re: New feature request: FlashBack Query  (RPK <rohitprakash123@indiatimes.com>)
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: ToDo: add documentation for operator IS OF
Next
From: Greg Smith
Date:
Subject: Re: [PATCHES] WIP patch - INSERT-able log statements