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 >> differently. > > 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 yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
