On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost <sfr...@snowman.net> wrote:
>> I disagree with Stephen's proposal that this should be in core, or
>> that it needs its own dedicated syntax. I think contrib is a great
>> place for extensions like this. That makes it a whole lot easier for
>> people to develop customized vesions that meet particular needs they
>> may have, and it avoids bloating core with a bunch of stuff that is
>> only of interest to a subset of users. We spent years getting sepgsql
>> into a form that could be shipped in contrib without substantially
>> burdening core, and I don't see why this feature should be handed any
> I don't exactly see how an extension or contrib module is going to be
> able to have a reasonable catalog structure which avoids the risk that
> renaming an object (role, schema, table, column, policy) will break the
> configuration without being part of core.
At some level, I guess that's true, but a custom GUC would get you
per-role and per-database and a custom reloption could take it
further. A security label provider specifically for auditing can
already associate custom metadata with just about any SQL-visible
object in the system.
> Add on to that the desire for
> audit control to be a grant'able right along the lines of:
> GRANT AUDIT ON TABLE x TO audit_role;
> which allows a user who is not the table owner or a superuser to manage
> the auditing.
As Tom would say, I think you just moved the goalposts into the next
county. I don't know off-hand what that syntax is supposed to allow,
and I don't think it's necessary for pgaudit to implement that (or
anything else that you may want) in order to be a viable facility.
>> In fact, considering how much variation there is likely to be between
>> auditing requirements at different sites, I'm not sure this should
>> even be in contrib at this point. It's clearly useful, but there is
>> no requirement that every useful extension must be bundled with the
>> core server, and in fact doing so severely limits our ability to make
>> further changes.
> For my part, I do view auditing as being a requirement we should be
> addressing through core- and not just for the reasons mentioned above.
> We might be able to manage all of the above through an extension,
> however, as we continue to add capabilities and features, new types and
> methods, ways to extend the system, and more, auditing needs to keep
> pace and be considered a core feature as much as the GRANT system is.
I think the fact that pgaudit does X and you think it should do Y is a
perfect example of why we're nowhere close to being ready to push
anything into core. We may very well want to do that someday, but not
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: