mirror of
https://github.com/postgres/postgres.git
synced 2026-04-21 14:19:26 -04:00
b6aa17e0ae
Per discussion, the time has come to do this. The handwriting has been on the wall at least since 9.0 that this would happen someday, whenever it got to be too much of a burden to support the float-timestamp option. The triggering factor now is the discovery that there are multiple bugs in the code that attempts to implement use of integer timestamps in the replication protocol even when the server is built for float timestamps. The internal float timestamps leak into the protocol fields in places. While we could fix the identified bugs, there's a very high risk of introducing more. Trying to build a wall that would positively prevent mixing integer and float timestamps is more complexity than we want to undertake to maintain a long-deprecated option. The fact that these bugs weren't found through testing also indicates a lack of interest in float timestamps. This commit disables configure's --disable-integer-datetimes switch (it'll still accept --enable-integer-datetimes, though), removes direct references to USE_INTEGER_DATETIMES, and removes discussion of float timestamps from the user documentation. A considerable amount of code is rendered dead by this, but removing that will occur as separate mop-up. Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us
15 lines
454 B
C
15 lines
454 B
C
/* Define to 1 if the system has the type `int64'. */
|
|
#undef HAVE_INT64
|
|
|
|
/* Define to 1 if `long int' works and is 64 bits. */
|
|
#undef HAVE_LONG_INT_64
|
|
|
|
/* Define to 1 if the system has the type `long long int'. */
|
|
#undef HAVE_LONG_LONG_INT
|
|
|
|
/* Define to 1 if `long long int' works and is 64 bits. */
|
|
#undef HAVE_LONG_LONG_INT_64
|
|
|
|
/* Define to 1 to build client libraries as thread-safe code.
|
|
* (--enable-thread-safety) */
|
|
#undef ENABLE_THREAD_SAFETY
|