Charlie Brady wrote:
From my point of view, what's egregious with packaged postgresql is that
it allows you to "upgrade" a postgresql installation to a state where the data is no longer accessable. At the least, one should be able to dump the data to SQL after upgrade.
There's been much discussion about what rpm can and cannot do. One thing rpm can do, however, is to run a pre-script which uses the files of a a previously installed version. A pre script could detect an upgrade from the old version which uses an incompatible backend format, and could then create the SQL dump (starting postmaster and waiting for it if required).
Maybe. What happens if you run out of space? Or have to choose available space from different partitions or network mounts? Or you don't have the space for the reload in the new format? These are all likely scenarios for database machines.
I don't buy the arguments that changes in the supported SQL language make automated upgrades of the backend data impossible. Dump, upgrade, re-import couldn't work if that were the case.
They may work, but you can't assume that the applications will work unchanged on the new version, or that the applications are all part of the same upgrade. For example, anything that relied on the implict casts that were removed between 8.2 and 8.3 won't work, so you'll need to convert back when you find that out. This doesn't mean the conversion can't be automated, just that the operator may need to make a few choices along the way, including when it is safe to remove the old version.