Add timestamp column to version_table

[Gabriel Raineri]

Adding such column can be useful to track when the migration was run.

[Patrick Scheid]

I would love to give this one a try. My overall idea would be like this:

1. Creation of new version tables

• Extend the version table with a update_timestamp column of type timestamptz
• Write an initial value with now() in the insert into statement

2. Handle updates

The challenge here is handling existing version tables. I would propose a change that leaves existing version tables alone. If a user wants this feature, we could provide documentation on migrating the version table.

• After acquiring the advisory lock, check the pg_catalog if a update_timestamp column is present
• If not, use the existing update statement that increments or decrements the version
• If it is present, use an extended update statement, to set update_timestamp to now()

What are your thoughts @jackc?

[Jack Christensen]

It's not something I've felt a particular need for, but if it were to be done I think it should be more extensive. That is, rather than simply record the time the last migration is run we should change the migration table to store a row for each migration with the migration number and the time it was run. This preserves more information and avoids the problem of what to do with the timestamp when rolling back.

As far as compatibility goes I suppose switching based on the structure of the version table is reasonable. Though I expect for there to be a tern v2 sometime this year (use pgx v5 and fs.FS) so maybe it would make sense to only make the change then (again if it is done at all).

[Patrick Scheid]

Yes, great idea! And waiting for a version v2 seems reasonable to me. Thank you very much.