[postgis-tickets] [PostGIS] #3721: PostGIS trunk no longer compiles against PostgreSQL 10 branch

[PostGIS]

#3721: PostGIS trunk no longer compiles against PostgreSQL 10 branch
---------------------------+--------------------------------
 Reporter:  robe           |      Owner:  pramsey
     Type:  defect         |     Status:  new
 Priority:  blocker        |  Milestone:  PostGIS PostgreSQL
Component:  postgis        |    Version:  trunk
 Keywords:  PostgreSQL 10  |
---------------------------+--------------------------------
 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.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3721>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.