| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, 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-30 19:04:25 |
| Message-ID: | 11708.1406747065@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> What I wish to avoid is the situation which exists around hstore.
> Perhaps I've got this wrong, but my recollection of the discussion
> leads me to believe that we can't have hstore in core becasue there's
> no simple migration path from an hstore-enabled installation to one
> where hstore is in core instead.
The issues around hstore have to do with how we'd get from userland
datatype OIDs to fixed-at-initdb-time datatype OIDs, in view of the fact
that said OIDs exist in user data on-disk (in arrays for instance). This
is pretty much completely unrelated to reloptions or other catalog data,
and it's not at all clear to me why an auditing extension would have
any such issue. If an auditing extension has any impact on the storage of
user data, what it's doing is hardly just auditing, eh?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-07-30 19:21:36 | Re: pgaudit - an auditing extension for PostgreSQL |
| Previous Message | Stephen Frost | 2014-07-30 19:02:29 | Re: pgaudit - an auditing extension for PostgreSQL |