Re: PostgreSQL Auditing

Robert,

This isn't wrong. I don't see anyone else trying to submit anything in
reference to auditing. Just because there have been multiple
implementations in the past, based on commit histories, there have only
been a few that tried getting into core or contrib (that i can find in
mailing list history). Currently, in 9.6, there is one version that is
trying to make it in. If Crunchy, or 2nd Quadrant, tried to get their
versions incorporated we would have a disagreement in implementation, but
either they are lying in wait, or they passively concur, by not actively
disagreeing.

I think if there was a valid commit path laid out for getting auditing into
core, or into contrib at least, most users would probably find that
sufficient. But it seems that every time someone tries to incorporate
auditing, there are countless and varied reasons to deny its inclusion.

David Steele's version of auditing builds on most of the prior pgaudit code
and incorporates a large amount of the feedback from 9.5's attempt.

I'm opening to testing and evaluating to see if it meets our compliance
requirements, but I am no where close to being a C developer, or having C
developers that could actually provide a meaningful review. One issue
along this thread already pops up, concerning the client_min_messages, and
how other patches in the pipeline for 9.6 would be required to enable the
auditing to meet compliance requirements.

It just seems after reading the mailing list history, that there is a lack
of interest by people with commit authority, even though there is a decent
interest in it from the community, and honestly, no one really likes
auditing, but its one of those damned if you do (in performance) and damned
if you don't (in legal) things.

Additionally Robert, given your professional status, you are by no means an
unbiased contributor in this discussion. Your stance on this matter shows
that you don't necessarily want the open source solution to succeed in the
commercial/compliance required space. Instead of arguing blankly against
inclusion can you at least provide actionable based feedback that if met
would allow patches of this magnitude in?

I'm personally fine with fiscally rewarding organizations that assist my
customer in succeeding, but its hard to convince my customer to fund open
source, even though they wouldn't be able to do 75% of what they do without
it. Based on past experience this is the same most open source
organizations face, especially when they don't have the marketing engine
that the large commercial players have.

Curtis

…

On Tue, Feb 2, 2016 at 5:23 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Feb 2, 2016 at 5:16 PM, David Steele <david(at)pgmasters(dot)net> wrote:
> > This sort of confusion is one of the main reasons I pursued inclusion in
> > core.
>
> But that's exactly wrong. When there is not agreement on one code
> base over another, that's the time it is most important not to pick
> one of them arbitrarily privilege it over the others. The *only* time
> it's appropriate to move something that could just as well as an
> extension into core is when (1) we think it's highly likely that users
> will want that particular thing rather than some other thing and (2)
> we think it's worth the burden of maintaining that code forever.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>