database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-31 17:02:12 +03:00
Code Activity

Change TRUE/FALSE to true/false

Browse Source 
The lower case spellings are C and C++ standard and are used in most
parts of the PostgreSQL sources.  The upper case spellings are only used
in some files/modules.  So standardize on the standard spellings.

The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so
those are left as is when using those APIs.

In code comments, we use the lower-case spelling for the C concepts and
keep the upper-case spelling for the SQL concepts.

Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
This commit is contained in:
Peter Eisentraut
2017-08-16 00:22:32 -04:00
parent 4497f2f3b3
commit 2eb4a831e5
216 changed files with 1168 additions and 1168 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/utils/hash/dynahash.c
View File

@@ -891,8 +891,8 @@ calc_bucket(HASHHDR *hctl, uint32 hash_val)
* HASH_ENTER_NULL cannot be used with the default palloc-based allocator,
* since palloc internally ereports on out-of-memory.
*
* If foundPtr isn't NULL, then *foundPtr is set TRUE if we found an
* existing entry in the table, FALSE otherwise. This is needed in the
* If foundPtr isn't NULL, then *foundPtr is set true if we found an
* existing entry in the table, false otherwise. This is needed in the
* HASH_ENTER case, but is redundant with the return value otherwise.
*
* For hash_search_with_hash_value, the hashvalue parameter must have been
@@ -1096,12 +1096,12 @@ hash_search_with_hash_value(HTAB *hashp,
* Therefore this cannot suffer an out-of-memory failure, even if there are
* other processes operating in other partitions of the hashtable.
*
* Returns TRUE if successful, FALSE if the requested new hash key is already
* Returns true if successful, false if the requested new hash key is already
* present. Throws error if the specified entry pointer isn't actually a
* table member.
*
* NB: currently, there is no special case for old and new hash keys being
* identical, which means we'll report FALSE for that situation. This is
* identical, which means we'll report false for that situation. This is
* preferable for existing uses.
*
* NB: for a partitioned hashtable, caller must hold lock on both relevant