> > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers