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