From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: plpython vs _POSIX_C_SOURCE
In-reply-to: <20230124190721.mi7l5c3n2tsrqjno@awork3.anarazel.de>
References: <20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de> <2265665.1674582915@sss.pgh.pa.us> <20230124190721.mi7l5c3n2tsrqjno@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 24 Jan 2023 11:07:21 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2320613.1674594966.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jan 2023 16:16:06 -0500
Message-ID: <2320614.1674594966@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2320614.1674594966%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Python's _POSIX_C_SOURCE value is set to a specific value in their confi=
gure
> script:

> if test $define_xopen_source =3D yes
> then
>   ...
>   AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from I=
EEE Stds 1003.1-2008)
> fi

Hm.  I looked into Python 3.2 (the oldest release we still support)
and it has similar code but

  AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEE=
E Stds 1003.1-2001)

So yeah it's fixed (or else not defined) for any particular Python
release, but could vary across releases.

> Solaris and AIX are the ones missing.
> I guess I'll test them manually. It seems promising not to need this stu=
ff
> anymore?

Given that hoverfly is AIX, I'm betting there's an issue there.

>> Anyway, I'm still of the opinion that what a11cf433413 tried to do
>> was the best available fix, and we need to do whatever we have to do
>> to plpython's headers to reinstate that coding rule.

> You think it's not a viable path to just remove the _POSIX_C_SOURCE,
> _XOPEN_SOURCE undefines?

I think at the least that will result in warnings on some platforms,
and at the worst in actual build problems.  Maybe there are no more
of the latter a dozen years after the fact, but ...

>> That would be nice.  This old code was certainly mostly concerned with
>> python 2, maybe python 3 no longer does that?

> There's currently no non-comment references to *printf in their headers.=
 The
> only past reference was removed in:
> commit e822e37946f27c09953bb5733acf3b07c2db690f
> Author: Victor Stinner <vstinner@python.org>
> Date:   2020-06-15 21:59:47 +0200
>     bpo-36020: Remove snprintf macro in pyerrors.h (GH-20889)

Oh, interesting.

> Which suggests an easier fix would be to just to do

> /*
>  * Python versions <=3D 3.8 otherwise define a replacement, causing
>  * macro redefinition warnings.
>  */
> #define HAVE_SNPRINTF

> And have that be enough for all python versions?

Nice idea.  We did not have that option while we were using HAVE_SNPRINTF
ourselves, but now that we are not I concur that this should work.
(I confirmed that their code looks the same in Python 3.2.)
Note that you'd better make it

#define HAVE_SNPRINTF 1

or you risk macro-redefinition warnings.

			regards, tom lane