Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > "Which tables are audited" would be available via the reloptions > field.
RLS could be implemented through reloptions too. Would it be useful to
some people? Likely. Would it satisfy the users who, today, are
actually asking for that feature? No (or at least, not the ones that
I've talked with). We could expand quite a few things to work through
reloptions but I don't see it as a particularly good design for complex
subsystems, of which auditing is absolutely one of those.
I've gotten quite a bit of push-back and been working through a much
more detailed (but, all-in-all, good, imv) design and roadmap for RLS
with targets for 9.5 and beyond. I simply do not understand why these
same concerns apparently don't apply to pgaudit. Being an extension
which lives in contrib can be, in many ways, worse than having nothing
at all distributed with PG because it causes pg_upgrade and backwards
compatibility issues.
> 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.
Auditing isn't going to be a polished and solved piece of core PG with
an implementation that uses only single additional column (even an
hstore or json column), imv.
> 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.
I disagree that new top-level syntax is completely off the table, but
I'm open to another solution for SQL-based auditing specifications. I
would argue that we must consider how we will support a permissions
system around auditing which differs from the owner of the relation or
owner of the database and certainly don't want the control over auditing
to require superuser rights.
> 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.
I'd love to see auditing happen in 9.5 too. I'd also like to see RLS in
9.5, but that doesn't mean I'm ignoring the concerns about making sure
that we have a good design which will add useful capabilities in 9.5
while allowing the more advanced capabilities to be added later.
> 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.
Sure.
> 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.
I think this will paint us into a corner such that we won't be able to
add the capabilities which the users who are most concerned about
auditing require. I really don't want that to happen as it will mean
that we have an auditing system for the users who like the idea of
auditing but don't have real security issues, while the large industries
we're targeting won't be able to use PG.
Thanks,
Stephen
signature.asc
Description: Digital signature
