Should I compile NetDRMS against Postgres 9.x?

If you can, you probably should.  As of late July 2014, Postgres will not support version 8.4 past 8.4.22.  There will be no more patches.  For those on federal facilities, "no more patches" means you will be mandated to upgrade the program or you will have lots of explaining to do.  
That said, the most compelling reason for not updating Postgres is if you are running Slony replication as an active master.  If you are a "Slony master", such as the JSOC at Stanford, then you cannot support Slony 1.x against Postgres 9.2.  Stanford's replication processes at this time require Slony 1.2, and Postgres 8.4.x is the last version supported for that particular Slony version.  However, if you are only a passive Slony recipient, getting slony files and database changes but never issuing any yourself, then you are not confined to any particular database version.  Before making any change you should first have a conversation with your systems administrator and your department about changing their database since they might have rules or scripts that require testing.  

If you're reading this and have decided to go forward with your 9.x compile, read further.  The author of this wiki page has only compiled as far as 9.2.  It is possible that further changes could be necessary for versions > 9.2 and your situation may be different.  However, for a NetDRMS 7 compilation against Postgres 9.2, the following may be of use.  

Compiling NetDRMS v.7 against Postgres 9.2 requires changing one line in the SUMS code, and ensuring config.local has the right paths (file located in the top netdrms source directory).  It may also require changes to local environment variables if you have an existing Postgres 8.4.x installed on the machine.  

If you already have a prior version of Postgres installed and want to compile NetDRMS against v. 9.x instead, set your $PATH and $LD_LIBRARY_PATH variables properly to reflect the Postgres 9.2 paths.  You might want to do this a .profile file and source it every time you log in to avoid confusing errata later.  Assign corresponding paths to Postgres-specific variables in config.local.

The change required to the SUMS code is one line in two places.  

Change two files in base/sums/libs/pg    named SUMLIB_RmDo.pgc and SUMLIB_RmDoX.pgc  and make this modification to line 9
{{{
// EXEC SQL TYPE uint64_t IS unsigned long long;
EXEC SQL TYPE uint64_t IS unsigned long int;
}}}

There you go - that's all that is required.

----

Here's a little program from Igor to test this integer change, and my output:

{{{
#include <stdio.h>

int main(int argc, char**argv) {
  unsigned long int var1;
  unsigned long long var2;

  printf ("unsigned long long [%d] and unsigned long int [%d]\n",sizeof(var2), sizeof(var1));


  return 0;
}

}}}
Save program as: long_int_size.c
then do
gcc -o long_int_size long_int_size.c
and then execute
./long_int_size

My results are as follows:
{{{
sdo3>  ./long_int_size
sdo3>  unsigned long long [8] and unsigned long int [8]
}}}