Re: pgsql: Fix thinko in previous commit
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix thinko in previous commit |
Дата | |
Msg-id | 25905.1349802456@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix thinko in previous commit (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-committers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Tom Lane wrote: >> Looking again at the spoonbill failure, it's striking that it gets as >> far as plpython before choking. The symptoms are consistent with the >> theory that USE_INLINE is getting #define'd by some Python header or >> other, after having *not* been defined by pg_config.h. Maybe we should >> rename that to PG_USE_INLINE? > Ahh, that makes a lot of sense, yes; and I see that the Python headers > in my machine do mention USE_INLINE (though this is not defined, even on > pyconfig.h), so it is indeed possible that on some other machines it is > defined somewhere in those headers. I will go rename ours. Thanks for > the research. I'd not tried a build with plpython on my old HPUX box recently, but looking into its Python headers I find $ grep -r USE_INLINE /usr/local/include/python2.5 /usr/local/include/python2.5/pyport.h:#undef USE_INLINE /* XXX - set via configure? */ /usr/local/include/python2.5/pyport.h:#elif defined(USE_INLINE) which means on this box things would have failed in the opposite direction (undefined references to non-provided external functions) without the rename. So that's the right fix for sure. >> It's (probably) not contributing to this particular breakage, but I >> can't say that I think undef'ing things like _POSIX_C_SOURCE midstream >> is a bright idea at all. Seems to me that could easily result in >> inconsistent results from reading different system header files. > Ugh. The more I think about that, the more worried I get. It's not just that _POSIX_C_SOURCE might be defined or not, it's that the *value* it has affects what definitions you get. At least that's how it looks on my box. So our existing code potentially allows Python.h to redefine it with a different value than what we'd defined it as, which could result in inconsistencies between the system headers included by postgres.h and those included later. I think this needs reconsideration. Not sure what to do about it exactly, though :-( regards, tom lane
В списке pgsql-committers по дате отправления: