Is this a typo?
Hi Hacker,
While working on the other patch and editing heapam.c, I noticed this in line 2251:
```
/*
* If tuple is cachable, mark it for invalidation from the caches in case
* we abort. Note it is OK to do this after releasing the buffer, because
* the heaptup data structure is all in local memory, not in the shared
* buffer.
*/
```
Is “cachable” a typo? I confirmed with a dictionary and it gave me “cacheable”. Maybe an acceptable old usage that I am not aware of? So, I want to confirm with the community.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
On Tue, Nov 11, 2025 at 2:33 PM Chao Li <li.evan.chao@gmail.com> wrote:
Hi Hacker,
While working on the other patch and editing heapam.c, I noticed this in line 2251:
```
/*
* If tuple is cachable, mark it for invalidation from the caches in case
* we abort. Note it is OK to do this after releasing the buffer, because
* the heaptup data structure is all in local memory, not in the shared
* buffer.
*/
```Is “cachable” a typo? I confirmed with a dictionary and it gave me “cacheable”. Maybe an acceptable old usage that I am not aware of? So, I want to confirm with the community.
FWIW, my AI tells me:
-----
The preferred and more widely accepted spelling is cacheable.
While "cachable" is recognized as an alternative spelling,
particularly in some historical or technical contexts, "cacheable" is
significantly more common in modern usage, including in official
documentation and general writing.
-----
Search reveals:
Postgres has 12x "cacheable"
Postgres has 3x "cachable" (including the one you cited)
IMO it's a typo. The correct spelling is "cacheable", so it should be
corrected where you reported and also in the other two places.
======
Kind Regards,
Peter Smith.
Fujitsu Australia
On Tue, Nov 11, 2025 at 4:45 PM Peter Smith <smithpb2250@gmail.com> wrote:
IMO it's a typo. The correct spelling is "cacheable", so it should be
corrected where you reported and also in the other two places.
+1
I think the incorrect spelling fits the usual pattern (movable,
valuable, believable, ... with moveable accepted but dying), and it's
definitely "caching" without the -e-, so it's probably a tempting
mistake to make, but apparently we're making new words out of bits of
French with the C preprocessor ## operator and ignoring all that. I
bet it's "cachable" en français though. My Oxford Concise lists only
the -e- form, so you have my vote. The online Merriam-Webster (I
think that's the main reference for US spelling?) doesn't list either
and suggests I might be looking for cashable.
Now can anyone explain why database people write "sargable[1]https://en.wikipedia.org/wiki/Sargable", but
universally pronounce it as "sargeable"? That shows the reason to
keep an e around before an a, in our chaotic spelling system, if you
can call it a system :-)
Thomas Munro <thomas.munro@gmail.com> writes:
I think the incorrect spelling fits the usual pattern (movable,
valuable, believable, ... with moveable accepted but dying), and it's
definitely "caching" without the -e-, so it's probably a tempting
mistake to make, but apparently we're making new words out of bits of
French with the C preprocessor ## operator and ignoring all that. I
bet it's "cachable" en français though. My Oxford Concise lists only
the -e- form, so you have my vote. The online Merriam-Webster (I
think that's the main reference for US spelling?) doesn't list either
and suggests I might be looking for cashable.
I tend to look to OneLook Dictionary Search:
Their set of dictionaries has multiple entries for "cacheable"
and only one for "cachable". I don't agree that the latter is
wrong exactly, because some people evidently use it and English
has no Académie Française to legislate what is right; but it's
clearly the less common spelling.
regards, tom lane
On Tue, Nov 11, 2025 at 12:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
I think the incorrect spelling fits the usual pattern (movable,
valuable, believable, ... with moveable accepted but dying), and it's
definitely "caching" without the -e-, so it's probably a tempting
mistake to make, but apparently we're making new words out of bits of
French with the C preprocessor ## operator and ignoring all that. I
bet it's "cachable" en français though. My Oxford Concise lists only
the -e- form, so you have my vote. The online Merriam-Webster (I
think that's the main reference for US spelling?) doesn't list either
and suggests I might be looking for cashable.I tend to look to OneLook Dictionary Search:
Their set of dictionaries has multiple entries for "cacheable"
and only one for "cachable". I don't agree that the latter is
wrong exactly, because some people evidently use it and English
has no Académie Française to legislate what is right; but it's
clearly the less common spelling.regards, tom lane
Thanks all for the clarification. Peter and Thomas expressed clear
preference for "cacheable", and Tom confirmed it is the more common
spelling. I just created a patch to replace all three occurrences
accordingly.
Best regards,
Chao Li (Evan)
---------------------
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
v1-0001-Changes-cachable-to-cacheable.patchapplication/octet-stream; name=v1-0001-Changes-cachable-to-cacheable.patchDownload
From be3ecd285b24ee5c70e14af640f823683cb33e06 Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <lic@highgo.com>
Date: Tue, 11 Nov 2025 13:16:10 +0800
Subject: [PATCH v1] Changes "cachable" to "cacheable"
Author: Chao Li <lic@highgo.com>
Discussion: https://postgr.es/m/5EBF1771-0566-4D08-9F9B-CDCDEF4BDC98@gmail.com
---
src/backend/access/heap/heapam.c | 4 ++--
src/backend/utils/cache/catcache.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 36fee9c994e..4b0c49f4bb0 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -2248,7 +2248,7 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
ReleaseBuffer(vmbuffer);
/*
- * If tuple is cachable, mark it for invalidation from the caches in case
+ * If tuple is cacheable, mark it for invalidation from the caches in case
* we abort. Note it is OK to do this after releasing the buffer, because
* the heaptup data structure is all in local memory, not in the shared
* buffer.
@@ -2700,7 +2700,7 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
CheckForSerializableConflictIn(relation, NULL, InvalidBlockNumber);
/*
- * If tuples are cachable, mark them for invalidation from the caches in
+ * If tuples are cacheable, mark them for invalidation from the caches in
* case we abort. Note it is OK to do this after releasing the buffer,
* because the heaptuples data structure is all in local memory, not in
* the shared buffer.
diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c
index 30ac1bd91be..b6408d46e2b 100644
--- a/src/backend/utils/cache/catcache.c
+++ b/src/backend/utils/cache/catcache.c
@@ -829,7 +829,7 @@ ResetCatalogCachesExt(bool debug_discard)
* kinds of trouble if a cache flush occurs while loading cache entries.
* We now avoid the need to do it by copying cc_tupdesc out of the relcache,
* rather than relying on the relcache to keep a tupdesc for us. Of course
- * this assumes the tupdesc of a cachable system table will not change...)
+ * this assumes the tupdesc of a cacheable system table will not change...)
*/
void
CatalogCacheFlushCatalog(Oid catId)
--
2.39.5 (Apple Git-154)
On Tue, Nov 11, 2025 at 6:27 PM Chao Li <li.evan.chao@gmail.com> wrote:
Thanks all for the clarification. Peter and Thomas expressed clear preference for "cacheable", and Tom confirmed it is the more common spelling. I just created a patch to replace all three occurrences accordingly.
Pushed. Thanks!
On Nov 12, 2025, at 09:36, Thomas Munro <thomas.munro@gmail.com> wrote:
On Tue, Nov 11, 2025 at 6:27 PM Chao Li <li.evan.chao@gmail.com> wrote:
Thanks all for the clarification. Peter and Thomas expressed clear preference for "cacheable", and Tom confirmed it is the more common spelling. I just created a patch to replace all three occurrences accordingly.
Pushed. Thanks!
Hi Thomas,
Thank you very much for taking care of this patch.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/