From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Auditing extension for PostgreSQL (Take 2) |
Date: | 2015-04-07 19:41:57 |
Message-ID: | 55243305.4050207@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/6/15 5:03 PM, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
>> The present version can trigger an audit trail event for a statement,
>> without tracking the object that was being audited. This prevents you
>> from searching for "all SQL that touches table X", i.e. we know the
>> statements were generated, but not which ones they were. IMHO that
>> makes the resulting audit trail unusable for auditing purposes. I
>> would like to see that functionality put back before it gets
>> committed, if that occurs.
>
> Is there a consensus that the current version is the one that we should
> be reviewing, rather than the one Abhijit submitted? Last I checked,
> that wasn't at all clear.
Well, this one is the commitfest thread of record.
At quick glance, my comments about "how does this map to specific
customer requirements" apply to the other submission as well.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-04-07 20:11:09 | Re: Row security violation error is misleading |
Previous Message | Peter Eisentraut | 2015-04-07 19:35:31 | Re: "rejected" vs "returned with feedback" in new CF app |