Horton

Re: python cleanup

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Eisentraut <peter_e@gmx.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-07-25T16:03:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move include for Python.h above postgres.h to eliminate compiler warning.

Andrew Dunstan <andrew@dunslane.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@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