Dimitri Fontaine wrote: > Tom Lane <t...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
