Re: [HACKERS] PG_MODULE_MAGIC checks and pg_migrator
Bruce Momjian br...@momjian.us writes: 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. That's what any extension author and/or packager is faced with. Using debian, it's easy enough to have more than one postgresql-server-dev-8.X package at the same time and then use VPATH builds. I guess the scripts I'm preparing for easing the debian packaging of extensions should be usable on other Unix systems too, after adapting some of the paths. http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2010-January/000546.html Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PG_MODULE_MAGIC checks and pg_migrator
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.ushttp://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
Re: [HACKERS] PG_MODULE_MAGIC checks and pg_migrator
Bruce Momjian br...@momjian.us writes: 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. [ yawn... ] By the time 8.5 (9.0?) ships, this will probably not be true. Quit stressing about it and figure on shipping a pg_migrator per version. 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. We are *not* doing that. The potential for error, and costly debug time, greatly outweighs any possible savings. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PG_MODULE_MAGIC
A module magic patch was added recently and I'm a bit uncertain what the implications are for the external PL modules. Does it affect them at all? Will I need to provide separate binaries for each bug fix release even though the API's do not change? Exactly how is the magic determined? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PG_MODULE_MAGIC
Thomas Hallgren [EMAIL PROTECTED] writes: A module magic patch was added recently and I'm a bit uncertain what the implications are for the external PL modules. Does it affect them at all? Yes. Will I need to provide separate binaries for each bug fix release even though the API's do not change? No, each major release (8.2, 8.3, etc). There are hardly ever any major releases where you wouldn't need a new compilation anyway ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG_MODULE_MAGIC
Tom Lane wrote: No, each major release (8.2, 8.3, etc). There are hardly ever any major releases where you wouldn't need a new compilation anyway ... True. I'm all in favor of a magic used this way. It will save me some grief. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
