Thanks for the review. On 16 October 2014 23:23, MauMau <maumau...@gmail.com> wrote:
> (3) > SELECT against a view generated two audit log lines, one for the view > itself, and the other for the underlying table. Is this intended? I'm not > saying that's wrong but just asking. Intended > (4) > I'm afraid audit-logging DML statements on temporary tables will annoy > users, because temporary tables are not interesting. Agreed > (5) > This is related to (4). As somebody mentioned, I think the ability to > select target objects of audit logging is definitely necessary. Without > that, huge amount of audit logs would be generated for uninteresting > objects. That would also impact performance. Discussed and agreed already > (6) > What's the performance impact of audit logging? I bet many users will ask > "about what percentage would the throughtput decrease by?" I'd like to know > the concrete example, say, pgbench and DBT-2. Don't know, but its not hugely relevant. If you need it, you need it. > (8) > The code looks good. However, I'm worried about the maintenance. How can > developers notice that pgaudit.c needs modification when they add a new SQL > statement? What keyword can they use to grep the source code to find > pgaudit.c? Suggestions welcome. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
