Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension - Mailing list pgsql-hackers

From Thom Brown
Subject Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Date
Msg-id CAA-aLv7dVgXTC51oUBCbMZa48X-51H6YzkrvSgH2Wu82ysoZug@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  (Noah Misch <noah@leadboat.com>)
Responses Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On 10 June 2015 at 14:41, Noah Misch <noah@leadboat.com> wrote:
> On Tue, Jun 09, 2015 at 03:54:59PM -0400, David Steele wrote:
>> I've certainly had quite the experience as a first-time contributor
>> working on this patch.  Perhaps I bit off more than I should have and I
>> definitely managed to ruffle a few feathers along the way.  I learned a
>> lot about how the community works, both the good and the bad.  Fear not,
>> though, I'm not so easily discouraged and you'll definitely be hearing
>> more from me.
>
> Glad to hear it.
>
>> The stated purpose of contrib is: "include porting tools, analysis
>> utilities, and plug-in features that are not part of the core PostgreSQL
>> system, mainly because they address a limited audience or are too
>> experimental to be part of the main source tree. This does not preclude
>> their usefulness."
>>
>> Perhaps we should consider modifying that language, because from my
>> perspective pg_audit fit the description perfectly.
>
> "What is contrib?" attracts enduring controversy; see recent thread "RFC:
> Remove contrib entirely" for the latest episode.  However that discussion
> concludes, that documentation passage is not too helpful as a guide to
> predicting contrib patch reception.  (Most recent contrib additions had an
> obvious analogy to an existing module, sidestepping the question.)

Is pg_audit being resubmitted for 9.6 at all?

Thom



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Additional role attributes && superuser review
Next
From: Tom Lane
Date:
Subject: Re: Feature or bug: getting "Inf"::timestamp[tz] by "regular" value