"Mikheev, Vadim" wrote:
> > > - 1 sec could be tooo long time interval for some uses of TT.
> >
> > So someone in the future can implement finer grains. If time travel
> > disappears this option is not open.
>
> Opened, with triggers -:)
> As well as Colour-Travel and all other travels -:)
Maybe you're right and time-travel should be relegated to the dustbin of
history. But it always seemed a really neat design ever since I read
about it 8 years ago or something.
It does seem to me that time is a much more fundamental idea to model
explicitely than Colour or any other thing you might dream up. The
concept that a data-store has a history is a very fundamental concept.
This can get very philosophical. Think about the difference between a
pure-functional programming language and a regular programming language.
One way of looking at it is that a pure-functional language models time
explicitely whereas a regular language models time implicitely. In a
pure-functional language a change of state is brought about by creating
a whole new state, never by destroying the previous state. The previous
state continues to exist as long as you have a need for it. Since I'm a
fan of pure functional languages this idea appeals to me.
On a practical note, the postgres time travel was very easy to use. It's
hard for me to see how a trigger mechanism could be as easy. For example
by default SELECT would always get the current values - sensible. If you
want historical values you have to add extra conditions, in a simple to
use syntax. The database took care of destroying historical data
according to your parameters. Can a trigger mechanism really make things
this easy?
