On 26 June 2014 14:59, Stephen Frost <sfr...@snowman.net> wrote: > I think this will paint us into a corner such that we won't be able to > add the capabilities which the users who are most concerned about > auditing require.
I'm sorry, but this seems exactly the wrong way around to me. The point here is that we have an extension, right now. Per table auditing can be supported trivially via reloptions. The alternative is to fatten the grammar with loads of noise words and invent some new specific catalog stuff. That gives us no new features over what we have here, plus it has a hard cost of at least 3 man months work - starting that now endangers getting a feature into 9.5. Doing that will force the audit feature to be an in-core only solution, meaning it cannot be tailored easily for individual requirements and it will evolve much more slowly towards where our users want it to be. So I see your approach costing more, taking longer and endangering the feature schedule, yet offering nothing new. The hard cost isn't something that should be ignored, we could spend money adding new features or we could waste it rewriting things. Cost may mean little to some, but we need to realise that increasing costs may make something infeasible. We have at most 1 more man month of funds to assist here, after that we're into volunteer time, which never goes far. Anyway, what we should do now is talk about what features we want and detail what the requirements are, so we stand a chance of assessing things in the right context. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers