Re: python cleanup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: python cleanup
Date: 2011-07-25 16:03:19
Message-ID: 10068.1311609799@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 07/25/2011 10:52 AM, Tom Lane wrote:
>> What is features.h, and have its authors read the POSIX standard?
>> AFAICS they have no business defining this symbol.

> [andrew(at)emma ~]$ rpm -q -f /usr/include/features.h
> glibc-headers-2.13-1.x86_64

Oh, for some reason I was thinking this was mingw-specific.

[ pokes around ... ] I still think it's a bad idea for the header
files to be defining this, but they'll probably point at the part
of the POSIX spec that says the results are undefined if the macro
is changed after the first system header is #included.

I can't immediately think of any way to actually do what you were
trying to do (ie, save and restore the definition of the macro).
I wonder whether it would be good enough to do this:

#include postgres.h

#include everything else we want except python headers

#undef _POSIX_C_SOURCE
#undef _XOPEN_SOURCE

#include python headers

... rest of .c file ...

This should only fail if (a) some macro imported from system headers
attempts to test the value of a feature macro, and (b) the results
vary between the system default setting and the setting the python
headers selected. Neither of these things seem very probable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-07-25 16:26:54 Re: WIP fix proposal for bug #6123
Previous Message Robert Haas 2011-07-25 15:40:09 Re: WIP fix proposal for bug #6123