Re: PostgreSQL Auditing - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PostgreSQL Auditing
Date
Msg-id CA+TgmoYcxXFDqof9UbQ_uU0eZ9sYBuiBRH0hChiWZ2VvapwMTA@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL Auditing  (Curtis Ruck <curtis.ruck+pgsql.hackers@gmail.com>)
Responses Re: PostgreSQL Auditing
List pgsql-hackers
On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck
<curtis.ruck+pgsql.hackers@gmail.com> wrote:
> 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 feel the need to respond to this.  I don't appreciate being called a
liar.  I do not block patches because having them included in
PostgreSQL would be to the detriment of my employer.  Ever.  That
would be dishonest and a betrayal of the community's trust.  Full
stop.  I have a track record of committing multiple large patches that
were developed by people working for EnterpriseDB's competitors (like
logical decoding) or that competed with proprietary features
EnterpriseDB already had (like foreign tables).  I spend countless
hours working on countless patches written by people who do not work
for, and have no commercial relationship with, my employer: and who
are sometimes working for a competitor.  I have worked hard to ensure
that EnterpriseDB makes major contributions to the PostgreSQL
community, such as parallel query.

Even if all of the above were not true, EnterpriseDB does not
currently have a feature that competes with pgaudit, and has no
current plans to try to develop one.  EDBAS does have an auditing
feature, but that feature is radically different from what pgaudit
does; arguing that I am trying to block pgaudit from going into core
because that feature exists is like arguing that I don't want
PostgreSQL to get a new frying pan because EnterpriseDB has a toy
boat.  Furthermore, to the extent that EnterpriseDB does have an
interest in having a feature like pgaudit, it would be to my advantage
for that feature to go *into* core.  After all, everything in
PostgreSQL is in EDBAS, but things on PGXN generally aren't.  In
short, your accusations are both  false and illogical.

I'm going to go ahead and make a suggestion: instead of showing up on
this mailing list and accusing the people who spend their time and
energy here trying to make PostgreSQL a better of being pigheaded
liars, I think that you should try to really understand how this
community works, how it makes decisions, what it does well, and what
it does poorly.  Then, I think you should argue for your positions in
a respectful way, carefully avoiding accusations of bad faith even
(and perhaps especially) in cases where you believe it may be present.
You will find that almost everyone here behaves in that way, and that
is what enables us to get along as well as we do and create a great
piece of software together.  Every single person who has responded to
your emails - and there have been a bunch - has done so with courtesy
and integrity, and yet you seem convinced (without a shred of
evidence, at least that you've presented) that anyone who doesn't
think pgaudit should go into core is either an idiot or part of some
sort of cabal.  Yet, if that were really true, there would be little
point in arguing, because the cabalists won't listen to you anyway,
and the idiots will make stupid decisions no matter what.  Perhaps you
should try starting from a different premise.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Re: Integer overflow in timestamp_part()
Next
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive