"David E. Wheeler" <da...@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... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
