On 5/15/17 02:48, Roel Janssen wrote: > Ah yes, I see the point. The problem here is that when new features are > added to PostgreSQL, and you rely upon them in your database schemas, > downgrading will most likely cause loss of information. > > Maybe we need a wrapper script that also makes a dump of all of the > data? Now that could become a security hole. > > Or the wrapper script warns about this situation, and recommends making > a (extra) back-up of the database before upgrading. > > Or.. the upgrade is something a user should do explicitly, basically > giving up on the "just works" concept. Guix already provides a nice way > to get the previous version of the exact binaries used before the > upgrade.
The best way to manage this with PostgreSQL is to make separate packages for each PostgreSQL major version. I see for example that you have packages gcc-4.9, gcc-5, gcc-6, etc. You should do the same with PostgreSQL, e.g., postgresql-9.5, postgresql-9.6, postgresql-10. Then you don't have to concern yourselves with how "upgrades" and "downgrades" should look for the users of your packaging system. Minor version upgrades are just installing the new package and restarting. Major version upgrades are figured out by the user. Downgrades between minor versions of the same major versions should mostly work. They are not well tested, if at all, but I don't think that's all that different from downgrading any other package. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
