Re: TOAST versus toast

On Mon, Feb 17, 2025 at 6:27 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Wed, Jan 15, 2025 at 10:38 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>>
>> On Thu, Jan 16, 2025 at 3:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >
>> > Peter Smith <smithpb2250(at)gmail(dot)com> writes:
>> > > During some recent reviews, I came across some comments mentioning "toast" ...
>> > > TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
>> > > Technique" [1].
>> >
>> > It is indeed an acronym, but usages such as "toasting" are all over
>> > our code and docs, as you see. I question whether changing that
>> > to "TOASTing" improves readability. I agree that consistently
>> > saying "TOAST table" not "toast table" is a good idea, but I'm
>> > not quite convinced that removing every last lower-case occurrence
>> > is a win, especially in these combined forms.
>> >

I took a look at this a few weeks ago and couldn't get excited about
it. It does seem to me that the cases where we use TOAST as a verb are
more readable when done in lower case, and this is pretty common in
everyday english/grammar; as an example, people would generally write
"the dr. lasered the tumor" not "the dr. LASERed the tumor". So I am
+1 on the idea of not uppercasing these instances, but the flip side
"should we ensure we are lower casing them" is interesting... we
usually do, but there are a few cases where we don't (typically where
they have been labeled as acronyms). the documentation on
pg_column_toast_chunk_id is a good example:

Shows the <structfield>chunk_id</structfield> of an on-disk
<acronym>TOAST</acronym>ed value. Returns <literal>NULL</literal>
if the value is un-<acronym>TOAST</acronym>ed or not on-disk. See
<xref linkend="storage-toast"/> for more information about
<acronym>TOAST</acronym>.

>
>
> I'm not particularly convinced that "TOAST table" is a good idea; but I don't hate it either.
>
> TOAST is a "technique", design feature, algorithm, process. When referring to that concept, using TOAST makes sense. The implementation artifacts are conveniently labelled e.g., "toast tables", and can be used in the same capitalization that one would write "foreign table" or "temporary table". Sure, we can define our made-up label as "TOAST tables" but it just makes it stand out unnecessarily in comparison to "temporary tables" and the like.
>
> I'd be more interested in making sure all TOAST references are in regards to the technique and lower-case the ones that aren't.
>

I kind of wondered about this, because I felt pretty used to seeing
the term "TOAST table", so I did some quick searches, and it looks
like we have about 20 cases where we use TOAST table vs about 10 where
we use toast table, specifically focusing on cases where we don't add
any markup to the word "toast", and about 20 more where we use
"<acronym>TOAST</acronym> table". So ISTM that folks are probably used
to seeing the term with upper case, but not universally so... so I
could probably get onboard with David's suggestion, although tbh I
probably would lean the other way.

Robert Treat
https://xzilla.net