[go: up one dir, main page]

Re: Auditing extension for PostgreSQL (Take 2)

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.

In response to Browse pgsql-hackers by date
  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