PostGIS trunk no longer compiles against PostgreSQL 10 branch

[robe]

Hmm I just looked at latest PostgreSQL 10.0 regress on debbie, and it's pretty ugly. Doesn't even make it past compile.

make[1]: Entering directory '/var/lib/jenkins/workspace/postgis/regress_pgdev/branches/2.4/libpgcommon'
gcc -I../liblwgeom -g -O2 -I/var/lib/jenkins/workspace/pg/rel/pg10.0w64/include/postgresql/server   -fPIC -DPIC  -Wall -Wmissing-prototypes  -c -o gserialized_gist.o gserialized_gist.c
In file included from gserialized_gist.c:23:0:
gserialized_gist.c: In function ‘gidx_from_gbox_p’:
gserialized_gist.c:98:25: error: ‘FLT_MAX’ undeclared (first use in this function)
     GIDX_SET_MIN(a,2,-1*FLT_MAX);
                         ^
gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’
 #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value))
                                                                           ^
gserialized_gist.c:98:25: note: each undeclared identifier is reported only once for each function it appears in
     GIDX_SET_MIN(a,2,-1*FLT_MAX);
                         ^
gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’
 #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value))
                                                                           ^
gserialized_gist.c: In function ‘gserialized_datum_get_gidx_p’:
gserialized_gist.c:277:27: error: ‘FLT_MAX’ undeclared (first use in this function)
    GIDX_SET_MIN(gidx,2,-1*FLT_MAX);
                           ^
gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’
 #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value))

Looks like this may be result of change in PostgreSQL 10.0. As best as I can guess from tracing first occurence of failure.

The smoking gun is this: ​http://debbie.postgis.net:8080/job/PG_Version_Dev_Git/2006/

​https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b9d092c962ea3262930e3c31a8c3d79b66ce9d43

Changes

    Remove now-dead code for !HAVE_INT64_TIMESTAMP. (details)

Commit b9d092c962ea3262930e3c31a8c3d79b66ce9d43 by Tom Lane



Remove now-dead code for !HAVE_INT64_TIMESTAMP.
This is a basically mechanical removal of #ifdef HAVE_INT64_TIMESTAMP 
tests and the negative-case controlled code.
Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us

}}

or this one:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c29aff959dc64f7321062e7f33d8c6ec23db53d3
{{
http://debbie.postgis.net:8080/job/PG_Version_Dev_Git/2007/changes#detail0
Commit c29aff959dc64f7321062e7f33d8c6ec23db53d3 by Tom Lane



Consistently declare timestamp variables as TimestampTz.
Twiddle the replication-related code so that its timestamp variables are
declared TimestampTz, rather than the uninformative "int64" that was
previously used for meant-to-be-always-integer timestamps. This resolves
the int64-vs-TimestampTz declaration inconsistencies introduced by
commit 7c030783a, though in the opposite direction to what was
originally suggested.
This required including datatype/timestamp.h in a couple more places 
than before.  I decided it would be a good idea to slim down that header
by not having it pull in <float.h> etc, as those headers are no longer
at all relevant to its purpose.  Unsurprisingly, a small number of .c
files turn out to have been depending on those inclusions, so add them
back in the .c files as needed.
Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us 
Discussion: https://postgr.es/m/27694.1487456324@sss.pgh.pa.us

Though I may have missed something since remove date specific code I don't see how that could affect us unless if something unintended was removed.