Re: GinPageIs* don't actually return a boolean

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GinPageIs* don't actually return a boolean
Дата
Msg-id CA+TgmoYzsEHA-VLAdyxE0qs9OcRzW=6vKFVHYzZaCur918OT_w@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  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
On Fri, Feb 12, 2016 at 9:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
>> 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?
>
> Well, the thing that is scaring me here is allowing a platform-specific
> definition of "bool" to be adopted.  If, for example, the compiler
> writer decided that that should be int width rather than char width,
> all hell would break loose.

That's true, but it doesn't really seem like a reason not to commit
this patch.  I mean, the coding here is (a) dangerous by your own
admission and (b) actually breaks on platforms for which we allege
support.  If we find out that somebody has implemented an int-width
bool we'll have some bigger decisions to make, but I don't see any
particular reason why we've got to make those decisions now.

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



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

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Patch: fix lock contention for HASHHDR.mutex
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)