Re: temporal support patch

>
> Well, the point is that I think many people have requirements that are
> (1) different from each other and (2) more complicated than the
> simplest case we can come up with. Some people will want to log the
> application user (or some other piece of extra data); others won't.
> Some people will want to record every change in a transaction; others
> won't. Some people will want to log time stamps; others won't; others
> still may want a "range" per row indicating the time that row version
> lived. Some people will want to delete history before it fills up the
> disk; others will want to keep it forever. Some people will want to
> clean up history created by "accidental" changes; others will want to
> make sure that the history is as tamper-proof as possible. That's
> why, of everything that's been said on this topic, I mostly agree with
> what Josh Berkus said upthread:
>
> # If you want something in core which will be useful to a lot of our
> # users, it needs to be simple and flexible. Not ornate with lots of
> # dependancies. The first version of it should be as simple and minimalist
> # as possible.
> #
> # Personally, I would prefer a tool which just made it simpler to build my
> # own triggers, and made it automatic for the history table to track
> # changes in the live table. I think anything we build which controls
> # what goes into the history table, etc., will only narrow the user base.
>

I can't agree - why we need a some simple solution based on tools,
that are available now? I don't think we have to be hurry in support
own proprietary solutions - when isn't difficult do it just with
available tools now.

Regards

Pavel