TRUE/FALSE vs true/false - Mailing list pgsql-hackers

Hi,

I looked at b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4
and I noticed that it's using TRUE, FALSE, true and false
inconsistently:

@@ -248,6 +249,7 @@ CreateSharedInvalidationState(void)               shmInvalBuffer->procState[i].nextMsgNum = 0;
/*meaningless */               shmInvalBuffer->procState[i].resetState = false;
shmInvalBuffer->procState[i].signaled= false;
 
+               shmInvalBuffer->procState[i].hasMessages = false;               shmInvalBuffer->procState[i].nextLXID =
InvalidLocalTransactionId;      }}
 

@@ -316,6 +316,7 @@ SharedInvalBackendInit(bool sendOnly)       stateP->nextMsgNum = segP->maxMsgNum;
stateP->resetState= false;       stateP->signaled = false;
 
+       stateP->hasMessages = false;       stateP->sendOnly = sendOnly;       LWLockRelease(SInvalWriteLock);


@@ -459,6 +461,19 @@ SIInsertDataEntries(const SharedInvalidationMessage *data, int n)
SpinLockRelease(&vsegP->msgnumLock);              }
 
+               /*
+                * Now that the maxMsgNum change is globally visible, we give
+                * everyone a swift kick to make sure they read the newly added
+                * messages.  Releasing SInvalWriteLock will enforce a full memory
+                * barrier, so these (unlocked) changes will be committed to memory
+                * before we exit the function.
+                */
+               for (i = 0; i < segP->lastBackend; i++)
+               {
+                       ProcState  *stateP = &segP->procState[i];
+                       stateP->hasMessages = TRUE;
+               }
+               LWLockRelease(SInvalWriteLock);       }}

@@ -499,11 +514,36 @@ SIGetDataEntries(SharedInvalidationMessage *data, int datasize)
...
+        * Note that, if we don't end up reading all of the messages, we had
+        * better be certain to reset this flag before exiting!
+        */
+       stateP->hasMessages = FALSE;
+

@@ -544,10 +584,16 @@ SIGetDataEntries(SharedInvalidationMessage *data, int datasize)
...       if (stateP->nextMsgNum >= max)               stateP->signaled = false;
+       else
+               stateP->hasMessages = TRUE;


Also, grepping for checking for or assigning bool values reveal that
"true" and "false" are used far more than "TRUE" and "FALSE":

[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w true | grep -v 'true"' | grep
= | wc -l
2446
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w false | grep -v 'false"' |
grep = | wc -l
2745
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w TRUE | grep -v 'TRUE"' | grep
= | wc -l
119
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w FALSE | grep -v 'FALSE"' |
grep = | wc -l
140

Shouldn't these get fixed to be consistent?

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de    http://www.postgresql.at/