Re: pg_migrator issue with contrib

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Exactly. And note that this is not pg_migrator's fault: a pg_dump
> dump and reload of the database exposes the user to the same risks,
> if the module author has not been careful about compatibility.

It seems to me the dump will contain text string representation of data
and pg_restore will run the input function of the type on this, so that
maintaining backward compatibility of the data type doesn't sound
hard. As far as the specific index support goes, pg_restore creates the
index from scratch.

So, from my point of view, supporting backward compatibility by means of
dump and restore is the easy way. Introducing pg_migrator in the game,
the data type and index internals upgrade are now faced to the same
problem as the -core in-place upgrade project.

Maybe we'll be able to provide the extension authors (not only contrib)
a specialized API to trigger in case of in-place upgrade of PG version
or the extension itself, ala Erlang code upgrade facility e.g.:
http://erlang.org/doc/reference_manual/code_loading.html#12.3

This part of the extension design will need help from C dynamic module
experts around, because it's terra incognita as far as I'm concerned.

Regards,
--
dim