Technically pg_migrator does not need the PG_MODULE_MAGIC version checks
because it doesn't do any data manipulation and it already checks the
new server version to determine if the function calls will resolve.
However, we currently require PG_MODULE_MAGIC for all loaded libraries,
and this adds additional compile requirements on pg_migrator.
For example, right now pg_migrator can migrate to 8.4 and 8.5, but there
is no way to distribute a binary that will migrate to both because you
need different shared libraries with different PG_MODULE_MAGIC values.
One possible solution would be to distribute an 8.4-compiled
pg_migrator, and an 8.5-compiled pg_migrator. That would work, except
once pg_migrator reaches an 8.5 version, things become very confusing
because you will potentially have pg_migrator 8.5 compiled for 8.4 and
8.5, and pg_migrator 8.4 compiled for 8.4 and 8.5.
One solution would be to drop migration support to 8.4 in pg_migrator
8.5, but that still leaves us with problems when we want to distribute a
pg_migrator 8.4 that can migrate to 8.5 alpha, e.g. on Windows.
Another option would be to distribute both 8.4 and 8.5 shared objects,
but that would require access to two source trees to perform the
compile, which seems very error-prone.
I am not sure what to suggest except perhaps that there be some way to
link in a shared object without the magic block checks.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
