On Mon, May 08, 2006 at 10:32:47AM -0400, Tom Lane wrote: > Martijn van Oosterhout <firstname.lastname@example.org> writes: > > I was trying to find variables that when changed would make some things > > corrupt. For example, a changed NAMEDATALEN will make any use of the > > syscache a source of errors. A change in INDEX_MAX_KEYS will break the > > GiST interface, etc. > > By that rationale you'd have to record just about every #define in the > system headers. And it still wouldn't be bulletproof --- what of > custom-modified code with, say, extra fields inserted into some widely > used struct?
I can see that. That's why I specifically aimed at the ones defined in pg_config_manual.h, ie, the ones marked "twiddle me". > ... So checking for identical catversion won't > accomplish much except to force additional recompile churn on people > doing development against CVS HEAD. The original proposal was just > to check for major PG version match. Ok, I've taken out CATVERSION and cut PG version to just the major version. I've also dropped the compiler and several others. > Another problem with an expansive list of stuff-to-check is where does > the add-on module find it out from? All these symbols are defined by including c.h only, which is included by postgres.h, so this is not an issue. I obviously didn't include any symbols that a module would need to add special includes for. The only outlier was CATVERSION but we're dropping that test. > I think that will just mean that we'll break every module at the start > of 8.2 freeze ;-). Unless we forget to change it to error, which IMHO > is way too likely. Ok, one week then. Not everyone follows -patches and will be mighty confused when a CVS update suddenly breaks everything. Have a nice day, -- Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature