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?
