From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgaudit - an auditing extension for PostgreSQL |
Date: | 2014-07-29 13:08:38 |
Message-ID: | 20140729130838.GB2791@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 26, 2014 at 09:59:59AM -0400, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs (simon(at)2ndQuadrant(dot)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 saw many mentions of pg_upgrade in this old thread. I think the focus
should be in pg_dump, which is where the SQL syntax or custom reloptions
would be dumped and restored. pg_upgrade will just use that
functionality. In summary, I don't think there is anything
pg_upgrade-specific here, but rather the issue of how this information will
be dumped and restored, regardless of whether a major upgrade is taking
place.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-07-29 13:51:54 | Re: pgaudit - an auditing extension for PostgreSQL |
Previous Message | Michael Paquier | 2014-07-29 13:00:26 | Re: Production block comparison facility |