4 ms·
From the tone of the article, I'm sure the author would stipulate that there isn't a perfect solution to this problem and which solution you choose will always
by infamia 2y ago
From the tone of the article, I'm sure the author would stipulate that there isn't a perfect solution to this problem and which solution you choose will always be contingent. The author's proposed solution works fine until you have schema changes, then there's a good chance you can no longer use your audit log to roll back changes. Sure, you might be able to go in and do something manually to account for schema changes, but this becomes increasingly untenable as the schema changes pile up. There are no easy answers.
- jitl 2y agoPostgres has built in functions for turning rows into JSON and JSON into rows. As long as you don’t add non-nullable columns, you can build a schema change tolerant audit log storing the previous row as JSONB. Of course before making a schema in production, it would be good to test the JSON coercion handles the new column correctly. I haven’t built an audit log using this functionality, but I have used it for bulk insert statements where binding each row/column individually would exceeded the parameter limit, and COPY was too awkward.