Thread: Re: TOAST versus toast

Re: TOAST versus toast

From
"David G. Johnston"
Date:
On Wed, Jan 15, 2025 at 10:38 PM Peter Smith <smithpb2250@gmail.com> wrote:
On Thu, Jan 16, 2025 at 3:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Smith <smithpb2250@gmail.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'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.

David J.

Re: TOAST versus toast

From
Robert Treat
Date:
On Mon, Feb 17, 2025 at 6:27 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Wed, Jan 15, 2025 at 10:38 PM Peter Smith <smithpb2250@gmail.com> wrote:
>>
>> On Thu, Jan 16, 2025 at 3:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >
>> > Peter Smith <smithpb2250@gmail.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
thatone would write "foreign table" or "temporary table".  Sure, we can define our made-up label as "TOAST tables" but
itjust 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
thataren'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



Re: TOAST versus toast

From
Robert Haas
Date:
On Fri, Mar 7, 2025 at 11:24 AM Robert Treat <rob@xzilla.net> wrote:
> everyday english/grammar; as an example, people would generally write
> "the dr. lasered the tumor" not "the dr. LASERed the tumor".

For the record, I wouldn't write either of those things if I wanted to
be certain of being understood. Using acronyms as verbs is inherently
fraught: it supposes that the reader both understands the acronym in
general and is able to pick up on what you're doing with it. If I say
that somebody got swatted, for example, you could either fail to know
what a SWAT team is (which I imagine is quite plausible in a
non-American context) or you could think that I just meant that they
were struck lightly with a rolled-up newspaper. Writing SWATted
instead of swatted makes it clear that an acronym was intended, but
you still have to know what the acronym means in order to understand
the sentence.

And, to me, that's the root of the issue here. Some of the
documentation references to toasting, detoasting, etc. are in sections
that specifically define that mechanism, but some are not. In
particular I see that a reference to "detoasted" has crept into the
ALTER TABLE documentation, a state of affairs that is very possibly my
fault. That kind of thing is probably always going to be a mess no
matter how you capitalize it, because the reader may not know the
term. You could link to the definition, but rewording the sentence is
often going to be even better. For example, in the specific context
where this is used in the ALTER TABLE documentation, "decompressed"
would be just as accurate as "detoasted" and easier to understand.

--
Robert Haas
EDB: http://www.enterprisedb.com