On Sun, Nov 05, 2006 at 09:11:07AM +0000, Simon Riggs wrote: > On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote: > > The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it > > will catch others off guard as well. > Did you find the documentation adequate? Could you locate what you > needed to know quickly and accurately? Do you think the change was > adequately explained?
The documentation was good - once I checked developer.postgresql.org for the latest copy. > If that hit you then we're gonna get a few more people trip the same > way. Do you have any suggestions as to how to avoid that experience for > others? I believe the release notes are inadequate. I've read them three times before and it never stood out for me. Currently it is referenced under: E.1.3.16. Source Code Changes - Add PG_MODULE_MAGIC header blocks to all shared object files (Martijn van Ousterhout) The magic block prevents version mismatches between loadable object files and servers. I believe I read this all three times as a "internal PostgreSQL change for developers only". The PG_MODULE_MAGIC has a wider impact that what is listed above. I suspect this should be listed under "Migration to 8.2" or "Server Changes" as "loadable modules are now required to include PG_MODULE_MAGIC to protect the server from accidentally loading an incompatible module - all loadable module authors must implement the change described in the documentation to allow their loadable modules to work properly in 8.2". Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match