Thread: [PATCH] Round 2: Magic block for modules
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
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. +
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
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
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