3 ms·
Please don't do this. It's a design/ architectural sin. It messes up your queries, commands and indexes and it's constant source of trouble. Here's a better wa
by vbilopav 2y ago
Please don't do this. It's a design/ architectural sin. It messes up your queries, commands and indexes and it's constant source of trouble.
Here's a better way:
https://medium.com/@vbilopav/custom-temporal-tables-in-postgresql-5a0e4045ab30 https://medium.com/@vbilopav/custom-temporal-tables-in-postg...
- dqv 2y agoWhat does it do when a table that already has that trigger on it gets altered (i.e. a new column is added)?
- vbilopav 2y agoIt's already built into code to check does trigger exists, check it out. As far as changes(alter table ) goes, I need to take history tables into consideration when writing migration scripts. Since I'm doing my migrations always with SQL scripts that not an issue. However, there's a concept of system event triggers in PostgreSQL that can intercept alter table statements, so I'm thinking to expand my solution to alter history tables automatically. Check it out: https://www.postgresql.org/docs/current/event-triggers.html https://www.postgresql.org/docs/current/event-triggers.html
- deleted 2y ago[deleted]