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.)
> 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?
If we implement per-object auditing configuration in-core, it can use a
real reloption. Apart from that, I don't see a really good reason yet to
put more things into the database.
> We'd also end up re-working the code to be called as part of PG core
> rather than through hook functions, of course, but I don't think those
> changes would be too bad compared to figuring out the other issues.
You're right (but we'd still want to use event triggers). Maybe it would
make sense to have an auditing hook that we can sprinkle calls to in all
the interesting places, though.
> Additionally, thought towards what the SQL-level syntax would be is
> another key point- would the main command be 'ALTER AUDIT'?
(I have some thoughts about that, but I'll discuss them later when I
have a bit more time to present them properly.)
-- Abhijit
