Re: pgsql: Fix thinko in previous commit
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix thinko in previous commit |
Дата | |
Msg-id | 2547.1349760458@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix thinko in previous commit (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix thinko in previous commit
|
Список | pgsql-committers |
I wrote: > But having said that, it seems there's something wrong with the > STATIC_IF_INLINE patch for the case where USE_INLINE doesn't get set. > I'm too tired to investigate right now, but if you manually disable > USE_INLINE in pg_config.h after configuring, do you see a problem? I summoned the energy to run a build with an old non-inline-aware C compiler, and it went through, so the explanation is not that simple. 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? BTW, just noticing that this theory espoused in plpython.h: * Undefine some things that get (re)defined in the Python headers. They aren't * used by the PL/Python code, and all PostgreSQL headers should be included * earlier, so this should be pretty safe. is entirely full of it, as the plpy_*.h files feel free to pull in random Postgres header files. Maybe that area needs another look. 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. regards, tom lane
В списке pgsql-committers по дате отправления: