On Tue, Feb 02, 2016 at 01:05:46AM +0000, Curtis Ruck wrote: > So Auditing, it seems that some people want auditing (myself, David Steele, > 2nd quadrant, and probably others). I personally love postgresql, but > until it can meet my annoying compliance requirements, I can't leverage it > fully as my organization spends more time on meeting compliance, than > actually doing development and engineering.
> So, in summary, what would it take to get the core PostgreSQL team to > actually let auditing patches into the next version? [PostgreSQL has a "core team" (pgsql-core@) that rarely rules on specific features. I'm interpreting "core PostgreSQL team" more broadly as "people who determine whether to accept patches".] Based on the last discussion, I expect it would take resolving these concerns: 1. Does PostgreSQL gain enough by having the extension in core instead of leaving the same extension in Github? (Tom) 2. Will the feature set stand the test of time as the one core auditing feature set, pleasing to most of the PostgreSQL users who seek auditing? It's fine if the initial patch has a subset of the eventual feature set, but it's bad if we later wish to undo UI decisions. (Tom, Heikki, Robert) Your own input would be especially helpful on this point. Would you describe the compliance requirements you have faced lately? References to external standards are fine, and lists of private requirements are also fine. If you can annotate a requirements list with the pgaudit feature used to meet each requirement, that would be even more helpful. 3. Does the implementation do what it claims to do, correctly? Any defects are likely to be security vulnerabilities, which amplifies the cost of fixing them after release. (Noah, Robert) Points (1) and (2) relax considerably for narrow core changes to support an external auditing system. For example, David's errhidefromclient() proposal faces a simpler journey, because it raises far fewer design questions. > P.S., do you know what sucks, having a highly performant PostGIS database > that works great, and being told to move to Oracle or SQL Server (because > they have auditing). Even though they charge extra for Geospatial support In the same sense that PostgreSQL has geospatial support, PostgreSQL 9.3 and later do have auditing. Get it from https://github.com/2ndQuadrant/pgaudit, just like you get PostGIS separately. I realize some sites forbid extensions like pgaudit and PostGIS, but this particular case you describe is fortunate not to have that problem. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
