Per feedback, here is an updated version. As was pointed out, the prior
version was checking stuff that either changed too often to be useful
or was never going to change at all. The error reporting is cleaned up
too, it now releases the module before throwing the error. It now only
checks four things:

Major version number (7.4 or 8.1 for example)
NAMEDATALEN
FUNC_MAX_ARGS
INDEX_MAX_KEYS

The three constants were chosen because:

1. We document them in the config page in the docs
2. We mark them as changable in pg_config_manual.h
3. Changing any of these will break some of the more popular modules:

FUNC_MAX_ARGS changes fmgr interface, every module uses this
NAMEDATALEN changes syscache interface, every PL as well as tsearch uses this
INDEX_MAX_KEYS breaks tsearch and anything using GiST.

I considered others but ultimatly rejected them. For example,
HAVE_INT64_TIMESTAMP, while changing the way timestamps are stored and
being configurable by a configure option, doesn't actually break
anything important (only the btree_gist example in contrib).

Any more comments?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEX4fgIB7bNG8LQkwRAvpCAJ0e+3gUkWYbwa21Jh4lJs nGSbhZgwCfQhH/
WAV4yaFT3RzNvu9i00mM8mQ=
=Eeqy
-----END PGP SIGNATURE-----

Patch applied. Thanks.

---------------------------------------------------------------------------


Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Per feedback, here is an updated version. As was pointed out, the prior
> version was checking stuff that either changed too often to be useful
> or was never going to change at all. The error reporting is cleaned up
> too, it now releases the module before throwing the error. It now only
> checks four things:
>
> Major version number (7.4 or 8.1 for example)
> NAMEDATALEN
> FUNC_MAX_ARGS
> INDEX_MAX_KEYS
>
> The three constants were chosen because:
>
> 1. We document them in the config page in the docs
> 2. We mark them as changable in pg_config_manual.h
> 3. Changing any of these will break some of the more popular modules:
>
> FUNC_MAX_ARGS changes fmgr interface, every module uses this
> NAMEDATALEN changes syscache interface, every PL as well as tsearch uses this
> INDEX_MAX_KEYS breaks tsearch and anything using GiST.
>
> I considered others but ultimatly rejected them. For example,
> HAVE_INT64_TIMESTAMP, while changing the way timestamps are stored and
> being configurable by a configure option, doesn't actually break
> anything important (only the btree_gist example in contrib).
>
> Any more comments?
>
> Have a nice day,
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > From each according to his ability. To each according to his ability to litigate.

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Patch applied. Thanks.

I hadn't gotten around to reviewing the revised version. Just to let
you know, I'm going to remove the separate header file pgmagic.h and
put the macro into fmgr.h as I'd suggested originally. The reason is
that the separate file turns the problem of making backward-compatible
modules from a simple "#ifdef PG_MAGIC_BLOCK" into a big does-that-
header-exist autoconf pushup. It's not worth that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>> Patch applied. Thanks.
>>
>
> I hadn't gotten around to reviewing the revised version.

Is it just me or is this happening a lot lately?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I hadn't gotten around to reviewing the revised version.

> Is it just me or is this happening a lot lately?

That security stuff took up a *lot* of time behind the scenes :-(

Normality is returning, slowly.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster