Re: New feature request: FlashBack Query

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: "RPK" <rohitprakash123(at)indiatimes(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: New feature request: FlashBack Query
Date: 2007-02-20 12:42:52
Message-ID: 60087.24.211.165.134.1171975372.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-02-20 13:16:51 Re: [PATCHES] WIP patch - INSERT-able log statements
Previous Message Pavel Stehule 2007-02-20 12:19:01 Re: ToDo: add documentation for operator IS OF