[vbilopav]

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-postg...

[dqv]

What does it do when a table that already has that trigger on it gets altered (i.e. a new column is added)?

[vbilopav]

It'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