[codernyc16]

You’d have to do that for all results, not just one. This is basically what an event sourced system does: you store all the events and fold your state, so you can “play back” to any point in time. You could theoretically reverse from the end, but I haven’t seen it done.

[setr]

Urbit ;-)

[Zenst]

A transactional database would tick that box, events are stored and can rollback to a point in time.

[acoma]

Not quite. Dropping a column or updating a row is typically irreversible.

[Zenst]

That does depend upon the database, but can be done in some without resorting to a backup.

[continuational]

In PostgreSQL, schema changes are transactional.

[anarazel]

> In PostgreSQL, schema changes are transactional.

With a few exceptions (that refuse to run in an explicit transaction): E.g. {CREATE, DROP} DATABASE, {CREATE, DROP} TABLESPACE, {CREATE INDEX, DROP INDEX, REINDEX} CONCURRENTLY, REINDEX {SCHEMA, SYSTEM, DATABASE}.

[zcrackerz]

Also, try adding a value to an enum via ALTER TYPE ... ADD VALUE

[anarazel]

Not anymore ;). Well, at least in the upcoming PG 12.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

  commit 212fab9926b2f0f04b0187568e7124b70e8deee5
  Author: Thomas Munro <[e-mail]>
  Date:   2018-10-09 12:51:01 +1300
  
      Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).

There's still some restrictions:

> This patch removes that restriction, and instead insists that an uncommitted enum value can't be referenced unless it belongs to an enum type created in the same transaction as the value.