* Simon Riggs (si...@2ndquadrant.com) wrote: > 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.
Can you explain how we are going to migrate from the proposed pgaudit
approach to an in-core approach with the flexibility discussed? That's
really what I'd like to hear and to discuss.
I don't understand why we shouldn't be considering and discussing that
at this point.
> The point here is that we have an extension, right now.
I understand that. We have a patch for async I/O too. We also have an
RLS patch today (one which has been around for a few months...). That
doesn't mean these things can just go in without any further discussion.
I can't just go commit RLS and ignore the concerns raised by Robert and
others simply because I have an implementation today, yet that seems to
be the thrust of this argument.
> 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.
I'm happy to hear your concerns regarding the level of effort required
and that we need to be pushing to have things worked through and
hopefully committed earlier in this cycle rather than waiting til the
end and possibly missing 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.
This makes less than zero sense to me- having it in core allows us
flexibility with regard to what it does and how it works (more so than
an extension does, in fact.. the extension is obviously constrained in
terms of what it is capable of doing). I agree that changes to an
in-core solution will need to follow the PG release cycle- but the same
is true of contrib modules. If you want your own release cycle for
pgaudit which is independent of the PG one, then you should be putting
it up on PGXN rather than submitting it to be included in contrib.
The rate of evolution is defined by those who are working on it, with
the caveat that new features, etc, happen as part of the PG release
cycle which are snapshots of where we are at a given point.
> So I see your approach costing more, taking longer and endangering the
> feature schedule, yet offering nothing new.
Just because you choose to ignore the additional flexibility and
capability which an in-core solution would offer doesn't mean that it
doesn't exist. Having a real SQL syntax which DBAs can use through the
PG protocol and tailor to their needs, with a permissions model around
it, is a valuable feature over and above what is being proposed here.
> 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.
I'm quite aware that there are costs to doing development. I do not
agree that means we should be compromising or putting ourselves in a
position which prevents us from moving forward.
> 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.
Sure, I had been doing that earlier in the thread before we got off on
this tangent..
Thanks,
Stephen
signature.asc
Description: Digital signature
