plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE
authorAndres Freund <andres@anarazel.de>
Wed, 25 Jan 2023 17:59:26 +0000 (09:59 -0800)
committerAndres Freund <andres@anarazel.de>
Wed, 25 Jan 2023 17:59:26 +0000 (09:59 -0800)
commit642e8821d713d75f142ef4eda14e490ba0fb810b
tree11d5db184f2e6afb650105fe9b809e3716bb54bc
parent23c12329a755ad9c70135463d3f067241daf1dcc
plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE

We undefined them to avoid warnings about macro redefinitions. But we haven't
fully followed the necessary include order, since at least 147c2482542, in
2011.  Recently the combination of the include order rules not being followed
and undefining _POSIX_C_SOURCE started to cause a compile failure, starting
with 03023a2664f. Undefining _POSIX_C_SOURCE hides clock_gettime(), which is
referenced in an inline function as of 03023a2664f, whereas it was a macro
before.

After seeing some evidence that undefining _POSIX_C_SOURCE et al isn't
required, I tried to build postgres with plpython on most of our supported
platforms (except DragonFlyBSD and Illumos, but similar systems were tested),
with/without the #undefines. No compiler warning / behavioral difference.

The oldest supported python version, 3.2, defines _POSIX_C_SOURCE to 200112L
ad _XOPEN_SOURCE to 600, whereas newer versions of python use 200809L/700
respectively. As _POSIX_C_SOURCE/_XOPEN_SOURCE will default to the newer
operating system on most platforms, it's possible that when using python 3.2
new warnings would be emitted - but that seems acceptable.

It's possible that this approach won't work on some older platforms. But
getting rid of most of the include-order complexity seems promising, and it's
an easily revertible patch if we end up having to go another way.

Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de
src/pl/plpython/plpython.h