Re: GinPageIs* don't actually return a boolean

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GinPageIs* don't actually return a boolean
Дата
Msg-id CA+TgmoYTUS2uH4S0+cWsab2wXW6gQnOR0m7daXnNChw3nRqZqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GinPageIs* don't actually return a boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GinPageIs* don't actually return a boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 12, 2016 at 8:48 AM, Andres Freund <andres@anarazel.de> wrote:
>>> E.g. if you include stdbool.h [ ginStepRight breaks ]
>
>> Ah-ha.  OK, now I get it.  So then I agree we should back-patch this
>> at least as far as 9.3 where MSVC 2013 became a supported platform,
>
> Um, no, that does not follow.  The unanswered question here is why,
> when we *have not* included stdbool.h and *have* typedef'd bool as
> just plain "char", we would get C99 bool behavior.  There is something
> happening there that should not be happening, and I'm not really satisfied
> with the explanation "Microsoft is brain-dead as usual".  I think we
> should dig deeper, because whatever is going on there may have deeper
> effects than we now realize.

http://www.postgresql.org/message-id/d2106c2d-0f46-4cf9-af27-54f81ef6e20c@postgrespro.ru
seems to explain what happens pretty clearly.  We #include something
which #includes something which #includes something which #includes
<stdbool.h>.  It's not that surprising, is it?  I mean, things with
"std" in the name figure to be commonly-included.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.