Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

Abhijit,

* Abhijit Menon-Sen (ams@2ndQuadrant.com) wrote:
> At 2014-06-30 09:39:29 -0400, sfrost@snowman.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.)

We're certainly not going to include this in the -contrib packages for
9.4-or-earlier, so I've not really been thinking about those concerns,
no.  Indeed, if you want that to be supported by packagers, they'd
probably be happier with it being an independent extension distributed
through pgxn or similar..  Having an extension for 9.4-and-earlier which
isn't in -contrib then be moved to -contrib for 9.5 is at least an
annoyance when it comes to packaging.

> > 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.

I do think people will complain a bit about such a change, but I expect
that to be on the level of grumblings rather than real issues.

> 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.)

Where would you store the information about the GRANTs?  In the
reloptions too?  Or would you have to write pg_upgrade to detect if
pgaudit had been installed and had played with the reloptions field to
then extract out the values from it into proper columns or an actual
table, not just for grants but for any other custom reloptions which
were used?  Were pgaudit to grow any tables, functions, etc, we'd have
to address how those would be handled by pg_upgrade also.  I don't think
that's an issue currently, but we'd have to be darn careful to make sure
it doesn't happen or we end up with the same upgrade issues hstore has.

We've absolutely had push-back regarding breaking things for people who
have installed extensions from -contrib by moving those things into core
without a very clearly defined way to *not* break them.  There have been
proposals in the past to explicitly allocate/reserve OIDs to address
this issue but those haven't been successful.

I'm not saying that I know it's going to be impossible- I'm asking
that we consider how this might move into core properly in a way that
will make it possible to pg_upgrade.  Part of that does include
considering what the design of the core solution will offer and what
feature set it will have..
Thanks,
    Stephen