From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: plpython vs _POSIX_C_SOURCE |
Date: | 2023-01-24 21:16:06 |
Message-ID: | 2320614.1674594966@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Python's _POSIX_C_SOURCE value is set to a specific value in their configure
> script:
> if test $define_xopen_source = yes
> then
> ...
> AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from IEEE 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 IEEE 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 stuff
> 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(at)python(dot)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 <= 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
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2023-01-24 21:17:23 | Re: heapgettup refactoring |
Previous Message | Andrew Dunstan | 2023-01-24 21:11:20 | Re: run pgindent on a regular basis / scripted manner |