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.
--
Les Mikesell
lesmikesell at gmail.com