On 25 June 2014 15:40, Stephen Frost <sfrost@snowman.net> wrote:
> * Abhijit Menon-Sen (ams@2ndquadrant.com) wrote:
>> At 2014-06-25 00:10:55 -0400, sfrost@snowman.net wrote:
>> > For my part, the nexts steps might be to consider how you'd migrate
>> > what you've provided for configuration into catalog tables
>>
>> I must confess that I do not understand what needs to be migrated into
>> the catalog tables, or why. Of course, pgaudit.log must be renamed, but
>> why can't it continue to be a GUC setting? (Fujii-san suggested that it
>> be integrated with log_statement. I'm not sure what I think of that, but
>> it's certainly one possibility.)
>
> What I was getting at are things like "what tables are to be audited,
> and for what users?". I thought pg_audit had this capability today
> (isn't that part of the request for the rlsextension field..?) and I'd
> want to see something like
>
> AUDIT SELECT ON table1 FOR role1;
>
>> > and how we'd address the concerns raised elsewhere regarding catalog
>> > access in cases where we're not in a transaction
>>
>> …by not putting things into the catalog?
>
> I just don't see that as viable.
"Which tables are audited" would be available via the reloptions
field. This is basically the difference between information being
stored within the reloptions field (think of its as an hstore column)
and being stored in a separate audit-specific column. I see no
difference between them, we just need to provide a view that extracts
the useful information. It is very important we add new things as
reloptions so that we don't have to continually add new code elsewhere
to handle all the new options we add.
I don't agree with adding "AUDIT ..." syntax to the parser and having
top-level SQL commands. That just bloats the parser for no particular
gain. With reloptions we already support all the required DDL. No
further work required.
We want an audit feature in core 9.5, but I don't see those adding SQL
and adding specific catalog columns as giving us anything at all. It
will still be an audit feature without them.
Many, many users do not want audit. Many do. So the idea is to allow
audit to be added in a way that doesn't affect everybody else.
So lets commit pgaudit now and spend time on genuine enhancements to
the functionality, not just rewriting the same thing into a different
form that adds no value.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
