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
PostgreSQLusers who seek auditing? It's fine if the initial patch has a subset of the eventual feature set, but it's
badif 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
facedlately? References to external standards are fine, and lists of private requirements are also fine. If you can
annotatea 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,
whichamplifies 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