"David E. Wheeler" <david@kineticode.com> writes:
> On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote:
>> Yes, that's my point too, against David's argument that "surely someone
>> must have solved it". What we have here is a new problem, so it's not
>> so clear that there's any solution at all (yet).
>
> Yeah, I didn't mean that someone must've solved it for PostgreSQL, but that
> this sort of problem must have been solved before, wherever binary data
> storage is an issue.
In the extension proposal you can find the idea of an upgrade hook
function called with current and new version of the extension as
arguments. This allows for the extension authors to provide the data
conversion support. We'd in fact want pg_migrator to find any columm
using a datatype offered by the extension and for each of them run:
UPDATE t SET col = ext_upgrade_function(current_version, new_version, col);
A way to indicate that no ondisk change has been made will be a nice
optimisation, allowing to entirely skip the UPDATE step. Those
information should be easy to get from each extension's metadata (which
can point to functions, like ext_ondisk_change(version, version)) and
from pg_depend (any user column hosting an extension provided datatype
should have a tuple there, right?).
The reactions to this part of the proposal where not very warm, in
particular some where concerned that we still have a table rewrite here,
which pg_migrator tries hard to avoid, AFAIUI. But upgrading ondisk
format without rewriting table content is not something I feel able to
help provide.
Regards,
--
dim
PS: the original proposal for the hook let the upgrade function find
which columns to upgrade, on reflexion it's not that friendly...