Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


	#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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group