Re: PostgreSQL Auditing

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Curtis Ruck <curtis(dot)ruck+pgsql(dot)hackers(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, José Luis Tallón <jltallon(at)adv-solutions(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Auditing
Date: 2016-02-03 03:26:27
Message-ID: CA+TgmoYcxXFDqof9UbQ_uU0eZ9sYBuiBRH0hChiWZ2VvapwMTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck
<curtis(dot)ruck+pgsql(dot)hackers(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-02-03 03:27:20 Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Previous Message Vitaly Burovoy 2016-02-03 03:01:14 Re: Integer overflow in timestamp_part()