Steve Midgley <science@misuse.org> writes:
> This seems pretty complex to address at any layer! But it would be a useful
> feature for some situations, for sure. It seems like the approach taken by
> Ruby/Rails and similar frameworks for "db migrations" might have some
> useful design patterns for you. Each transaction has a link to its future
> and past transaction. If the system wants to traverse from "migration 6 to
> migration 3" and the DB is currently at migration 6 (stored a version
> number in the db itself), it runs the exit function to downgrade to
> migration 5, then runs the logic for migration 5, then runs the downgrade
> to 4, etc.
> It can be slow, as implemented, but it allows you to attach logic to every
> step forward and backward in time that ensures you can handle even
> structure changes in the tables, etc (as well as changing lookup values in
> tables, etc).
> Might be worth considering as a design model?
If you end up building things that way, PG's "extensions" could be a
useful way to package it. What Steve is calling a "migration" corresponds
to an extension version, and you can provide scripts to go in either
direction between versions.
regards, tom lane
