plpython vs _POSIX_C_SOURCE

Hi,

A recent commit of mine [1] broke compilation of plpython on AIX [2]. But my
commit turns out to only be very tangentially related - it only causes a
failure because it references clock_gettime() in an inline function instead of
a macro and, as it turns out, plpython currently breaks references to
clock_gettime() and lots of other things.

From [2]
> There's nice bit in plpython.h:
>
> /*
>  * Include order should be: postgres.h, other postgres headers, plpython.h,
>  * other plpython headers.  (In practice, other plpython headers will also
>  * include this file, so that they can compile standalone.)
>  */
> #ifndef POSTGRES_H
> #error postgres.h must be included before plpython.h
> #endif
>
> /*
>  * Undefine some things that get (re)defined in the Python headers. They aren't
>  * used by the PL/Python code, and all PostgreSQL headers should be included
>  * earlier, so this should be pretty safe.
>  */
> #undef _POSIX_C_SOURCE
> #undef _XOPEN_SOURCE
>
>
> the relevant stuff in time.h is indeed guarded by
> #if _XOPEN_SOURCE>=500
>
>
> I don't think the plpython actually code follows the rule about including all
> postgres headers earlier.
>
> plpy_typeio.h:
>
> #include "access/htup.h"
> #include "fmgr.h"
> #include "plpython.h"
> #include "utils/typcache.h"
> [...]
>
> The include order aspect was perhaps feasible when there just was plpython.c,
> but with the split into many different C files and many headers, it seems hard
> to maintain. There's a lot of violations afaics.
> 
> The undefines were added in a11cf433413, the split in 147c2482542.


The background for the undefines is that _POSIX_C_SOURCE needs to be defined
the same for the whole compilation, not change in the middle, and Python.h
defines it. To protect "our" parts a11cf433413 instituted the rule that all
postgres headers have to be included first. But then that promptly got broken
in 147c2482542.

But apparently the breakage in 147c2482542 was partial enough that we didn't
run into obvious trouble so far (although I wonder if some of the linkage
issues we had in the past with plpython could be related).


I don't see a good solution here. I don't think the include order can
trivially be repaired, as long as plpy_*.h headers include postgres headers,
because there's no way to order two plpy_*.h includes in a .c file and have
all postgres headers come first.


The most minimal fix I can see is to institute the rule that no plpy_*.h
header can include a postgres header other than plpython.h.


A completely different approach would be to for our build to acquire the value
of _POSIX_C_SOURCE _XOPEN_SOURCE from Python.h and define them when compiling
plpython .c files. That has some dangers of incompatibilities with the rest of
the build though.  But it'd allow us to get rid of an obviously hard to
enforce rule.

Or we could see what breaks if we just don't care about _POSIX_C_SOURCE -
evidently we haven't succeeded in making this work for a long time.


Some other semi-related things:

An old comments:
/* Also hide away errcode, since we load Python.h before postgres.h */
#define errcode __msvc_errcode

but we don't do include Python.h before postgres.h...

We try to force linking to a non-debug python:
#if defined(_MSC_VER) && defined(_DEBUG)
/* Python uses #pragma to bring in a non-default libpython on VC++ if
 * _DEBUG is defined */
#undef _DEBUG

Which seems ill-advised? That's from d8f75d41315 in 2006.


python scribbling over our macros:
/*
 * Sometimes python carefully scribbles on our *printf macros.
 * So we undefine them here and redefine them after it's done its dirty deed.

I didn't find code in recent-ish python to do that. Perhaps we should try to
get away with not doing that?


Greetings,

Andres Freund

[1] https://postgr.es/m/E1pJ6NT-004jOH-DF@gemulon.postgresql.org
[2] https://postgr.es/m/20230121190303.7xjiwdg3gvb62lu3@awork3.anarazel.de