The SQL Standard actually specifies two related but separate approaches to versioning: - system-versioned tables, which is the focus of this extension. This ca

The SQL Standard actually specifies two related but separate approaches to versioning: - system-versioned tables, which is the focus of this extension. This can be implemented purely database-side, and the application doesn't even need to know whether (certain) tables are system-versioned. This is mainly intended to offer change tracking and auditing in a standard way, to replace all the home-grown solutions to do the same. - application-versioned tables, which I think Postgres already supports natively. This puts the application in control of the timespans in which a row is considered valid, and is probably what you would use for retroactive (or planned) updates to business records. I'm not sure if the standard specifies how these two versioning systems interact, but by combining both strategies, you could in theory have a full system-versioned record of who made which changes to take effect on which date.