Ideas for v0.8

  • Additional columns in audit_table_log and audit_column_log storing the statement_timestamp to allow for properly reverting multiple DDL changes that happened in one transaction.
  • Allow users to reuse existing unique ID columns as the table's audit_id. Are there any side-effects if such custom audit_ids are not following a global sequence?
  • Revisit restore algorithms that work both with old_data and new_data columns of row_log table
  • Add replay API to repeat certain transactions based on the new_data log
  • Add more event triggers for schema changes
  • More testing

General ideas

  • Branching strategy
  • Table partitioning strategy for row_log table (maybe pg_pathman can help)
  • Abandon triggers and go for logical decoding
  • Can I use WAL to create the same audit trail?