pgsql: plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE - Mailing list pgsql-committers

From Andres Freund
Subject pgsql: plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE
Date
Msg-id E1pKk3r-005RxD-L7@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
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

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/642e8821d713d75f142ef4eda14e490ba0fb810b

Modified Files
--------------
src/pl/plpython/plpython.h | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Avoid type cheats for invalid dsa_handles and dshash_table_handl
Next
From: Peter Geoghegan
Date:
Subject: pgsql: Add eager and lazy freezing strategies to VACUUM.