Re: PostgreSQL Auditing - Mailing list pgsql-hackers
| From | Curtis Ruck |
|---|---|
| Subject | Re: PostgreSQL Auditing |
| Date | |
| Msg-id | CAFgGLFezhdM3QuoBeVUaa0DomG5eQngXECLJCx=HqPr28cn-Rw@mail.gmail.com Whole thread Raw |
| In response to | Re: PostgreSQL Auditing (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: PostgreSQL Auditing
Re: PostgreSQL Auditing Re: PostgreSQL Auditing |
| List | pgsql-hackers |
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@gmail.com> wrote:
On Tue, Feb 2, 2016 at 5:16 PM, David Steele <david@pgmasters.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
pgsql-hackers by date: