Re: pgaudit - an auditing extension for PostgreSQL

From: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2014-06-30 14:08:51
Message-ID: 20140630140851.GA3437@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2014-06-30 09:39:29 -0400, sfrost(at)snowman(dot)net wrote:
>
> I certainly don't feel like it's the solution which extension authors
> are looking for and will be happy with

I don't know if there are any other extension authors involved in this
discussion, but I'm not shedding any tears over the idea. (That may be
because I see operational compatibility with 9.[234] as a major plus,
not a minor footnote.)

> > As Tom would say, I think you just moved the goalposts into
> > the next county.

(And they're not even the same distance apart any more. ;-)

> That's fine- but don't push something in which will make it difficult
> to add these capabilities later

I've been trying to understand why a pgaudit extension (which already
exists) will make it difficult to add a hypothetical "GRANT AUDIT ON
goalpost TO referee" syntax later. About the only thing I've come up
with is people complaining about having to learn the new syntax when
they were used to the old one.

Surely that's not the sort of thing you mean? (You've mentioned
pg_upgrade and backwards compatibility too, and I don't really
understand those either.)

-- Abhijit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-30 14:09:39 Re: RLS Design
Previous Message Robert Haas 2014-06-30 14:05:44 Re: Spinlocks and compiler/memory barriers