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 <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
