Re: PostgreSQL Audit Extension - Mailing list pgsql-hackers

On Wed, Feb 3, 2016 at 12:38 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
>> Right now that may be true, although it wouldn't surprise me very much
>> to find out that other people have written such extensions and they
>> just didn't get as much press.  Also, consider the future.  It is
>> *possible* that your version of pgaudit will turn out to be the be-all
>> and the end-all, but it's equally possible that somebody will fork
>> your version in turn and evolve it some more.  I don't see how you can
>> look at the pgaudit facilities you've got here and say that this is
>> the last word on auditing and all PostgreSQL users should be content
>> with exactly that facility.  I find that ridiculous.  Look me in the
>> eye and tell me that nobody's going to fork your version and evolve it
>> a bunch more.
>
> This rings hollow to me.  JSON got included with an admittedly weak feature
> set and then got significantly improved upon in subsequent releases.

True.  But most of that was adding, not changing.  Look, fundamentally
this is an opinion question, and everybody's entitled to an opinion on
whether pgaudit should be in core.  I have given mine; other people
can think about it differently.

> Those
> who would be incline to fork pgaudit, seeing it already being in core, would
> more likely and to the benefit of the community put that work into improving
> the existing work.  My off-the-cuff understanding is that some current big
> features (namely the parallel-related stuff) are also taking this "lets
> commit smaller but still useful pieces" into core to build up to this
> super-feature we want working two years from now.  I don't see any
> fundamental reason auditing couldn't be given the same opportunity to
> improve inside core.

Well, it means that every change has to be dealt with by a PostgreSQL
committer, for one thing.  We don't have a ton of people who have the
skillset for that, the time to work on it, and the community's trust.

> The other major downside of having it in core is that now the feature
> release cycle is tied to core.  Telling PostGIS they can only release new
> features when new versions of PostgreSQL come out would be an unacceptable
> situation.

Yep.

> The best of both worlds would be for core to have its own implementation
> written as an extension and to readily allow for other implementations to be
> plugged in as well.  As your alluded to above there are likely a number of
> things core really needs to enable such functionality without providing the
> entire UI - leaving that for extensions.

I really think this is not for the best.  People who write non-core
extensions are often quite unhappy when core gets a feature that is
even somewhat similar, because they feel that this takes attention
away from their work in favor of the not-necessarily-better work that
went into core.

> A bit short-sighted maybe.  Endorsing and including such a feature could
> open PostgreSQL up to a new market being supported by people who right now
> are not readily able to join the PostgreSQL community because they cannot
> invest the necessary resources to get the horses put before the cart.  Those
> people, if they could get their clients to more easily use PostgreSQL, may
> just find it worth their while to then contribute back to this new frontier
> that has been opened up to them.  This would ideally increase the number of
> contributors and reviewers within the community which is the main thing that
> is presently needed.

This is based, though, on the idea that they must not only have the
feature but they must have it in the core distribution.  And I'm
simply not willing to endorse that as a reason to put things in core.
Maybe it would be good for PostgreSQL adoption, but if everything that
somebody won't use unless it's in core goes in core, core will become
a bloated, stinking mess.

>> > I'll be the first to admit that the design is not the prettiest.  Trying
>> It's entirely reasonable for the community NOT to want to
>> privilege one implementation over another.
>
> This, not so much.

No, this is ABSOLUTELY critical.  Suppose EnterpriseDB writes an
auditing solution, 2ndQuadrant writes an auditing solution, and Cruncy
Data writes an auditing solution, and the community then picks one of
those to put in core.  Do you not think that the other two companies
will feel like they got the fuzzy end of the lollipop?  The only time
this sort of thing doesn't provoke hard feelings is when everybody
agrees that the solution that was finally adopted was way better than
the competing things.  If you don't think this is a problem, I
respectfully suggest that you haven't seen enough of these situations
play out.

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