Аудит изменения данных PostgreSQL

Возникла необходимость вести аудит postgresql изменения данных в существующей системе.

Требования:

• Простота подключения/отключения логгирования отдельных таблиц.
• Сократить до минимума изменения в уже существующих функциях БД.
• Минимизировать деградацию производительности.

Первая мысль была добавить в логгируемые таблицы поля _user, _create_date, _delete_date.

На операции INSERT, UPDATE, DELETE повесить триггеры, работающие с этими полями.
При добавлении записи заполнять поля _user и _create_date.

Вместо обновления делать копию обновляемой строки (с измененными значениями), а в самой обновляемой строке заполнять поле _delete_date.

Вместо удаления записи заполнять поле _delete_date.

При обращении к такой таблице в блок WHERE необходимо добавлять _delete_date IS NULL.

Этот механизм мог бы сработать, если бы был заложен в архитектуру БД изначально, но у нас к моменту внедрения логгирования было написано более 3000 функций, в каждую из которых пришлось бы вносить изменения.

Затем появилась идея хранить логи отдельно от данных. Идея заключалась в следующем:
В схеме logs создается копия структуры таблицы плюс несколько служебных полей.

На каждую логгируемую таблицу вешается триггер, который выполняет всю грязную работу по сохранению изменившихся данных.