On 26 June 2014 14:59, Stephen Frost <sfrost@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
