Dimitri Fontaine wrote:
> Tom Lane <tgl@sss.pgh.pa.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.
At a minimum it would be great if items could mark themselves as
non-binary-upgradable. Perhaps the existence of a symbol in the *.so
file could indicate that, or a function call could be made and you pass
in the old and new major version numbers and it would return true/false
based on binary upgradeability.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
