Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

On 30 June 2014 16:20, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Mon, Jun 30, 2014 at 9:39 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> >> I think the fact that pgaudit does X and you think it should do Y is a
>> >> perfect example of why we're nowhere close to being ready to push
>> >> anything into core.  We may very well want to do that someday, but not
>> >> yet.
>> >
>> > That's fine- but don't push something in which will make it difficult to
>> > add these capabilities later (and, to be clear, I'm not asking out of
>> > pipe dreams and wishes but rather after having very specific discussions
>> > with users and reviewing documents like NIST 800-53, which is publically
>> > available for anyone to peruse).
>>
>> I don't think that's a valid objection.  If we someday have auditing
>> in core, and if it subsumes what pgaudit does, then whatever
>> interfaces pgaudit implements can be replaced with wrappers around the
>> core functionality, just as we did for text search.
>
> I actually doubt that we'd be willing to do what we did for text search
> again.  Perhaps I'm wrong, which would be great, but I doubt it.
>
>> But personally, I think this patch deserves to be reviewed on its own
>> merits, and not the extent to which it satisfies your requirements, or
>> those of NIST 800-53.
>
> eh?  The focus of this patch is to add auditing to PG and having very
> clearly drawn auditing requirements of a very large customer isn't
> relevant?  I don't follow that logic at all.  In fact, I thought the
> point of pgaudit was specifically to help address the issues which are
> being raised from this section of our user base (perhaps not those who
> follow NIST, but at least those organizations with similar interests..).

It's not clear to me how NIST 800-53 mandates the use of SQL (or any
other) language statements for auditing. I strongly doubt that it
does, but I am happy to hear summaries of large documents, or specific
references to pages and paragraphs, just as we would do for SQL
Standard. There is no other difference between a function and a
statement - both may create catalog entries; I agree we need catalog
entries so that auditing config can itself be audited.

The rest of this argument seems to revolve around the idea that
"in-core" and "extension"/contrib are different things. That is much
more of a general point and one that is basically about development
style. We've built logical replication around the idea that the
various plugins can be the "in-core" version sometime in the future,
so anything you say along those lines affects that as well as sepgsql,
pgcrypto, pg_stat_statements etc.. . Adding things to the grammar, to
pg_proc.h and other hardcoding locations is seriously painful and
timeconsuming, one of the reasons why extensions and background
workers exist.

But if you missed it before, I will say it again: we have a patch now
and 2ndQuadrant has a limit on further funding. If you want to reject
pgaudit and move on to something else, lets start discussing that
design and consider who has the time (and implicitly the money) to
make that happen. We can pick the best one for inclusion in 9.5 later
in the cycle.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services