From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: taking stdbool.h into use |
Date: | 2017-11-08 23:19:52 |
Message-ID: | CAB7nPqQPKygbqhQr06NWW0pRacDTv4BUWCYqm7oh2URtcFf74A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 9, 2017 at 1:46 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 10/29/17 08:50, Michael Paquier wrote:
>> I spotted a couple of other things while looking at your patches and
>> the code tree.
>>
>> - return (ginCompareItemPointers(&btree->itemptr, iptr) > 0) ? TRUE : FALSE;
>> + return (ginCompareItemPointers(&btree->itemptr, iptr) > 0) ? true : false;
>> You could simplify that at the same time by removing such things. The
>> "false : true" pattern is less frequent than the "true : false"
>> pattern.
>
> I have found many more instances like that. It might be worth
> simplifying a bit, but that sounds like a separate undertaking.
Yeah, I just mentioned one for reference. And I can see 66 instances.
It may be not worth changing either to simplify back-patching.
>> Some comments in the code still mention FALSE or TRUE:
>> - hashsearch.c uses FALSE in some comments.
>> - In execExpr.c, ExecCheck mentions TRUE.
>
> That one is an SQL TRUE, so I left it.
Oops. You are right. I tried to be careful with what was referring to SQL and C.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Asim Praveen | 2017-11-08 23:25:32 | Re: [PATCH] Assert that the correct locks are held when calling PageGetLSN() |
Previous Message | Luke Lonergan | 2017-11-08 23:07:08 | Re: Pg V10: Patch for bug in bonjour support |