TOAST versus toast

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.

- "toasted" becomes "TOASTed".
- "toastable" becomes "TOAST-able"

Those two choices seem inconsistent...

- "untoasted" becomes "un-TOASTed"
- "detoasted" is unchanged (and so is "detoast")

Hm, there seems a risk of confusion between "not toasted" (a
statement of fact about the contents of a Datum) versus "detoasting"
(the act of expanding a toasted datum to full form). I'd prefer
to say "not toasted" than "untoasted" because the latter feels like
it could also mean "detoasted". (And as I write this para, I'm
having a hard time wanting to upcase the words, which reinforces
my doubts about s/toast/TOAST/g.)

regards, tom lane

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.

Hi, thanks for the reply.

How about I reduce the scope by only tackling the uncontroversial
stuff, and leave all those "combined forms" for another day?

Attached is the reduced patch for changes to the documentation.

- "toasted" becomes "TOASTed".
- "toastable" becomes "TOAST-able"

Those two choices seem inconsistent...

- "untoasted" becomes "un-TOASTed"
- "detoasted" is unchanged (and so is "detoast")

Hm, there seems a risk of confusion between "not toasted" (a
statement of fact about the contents of a Datum) versus "detoasting"
(the act of expanding a toasted datum to full form). I'd prefer
to say "not toasted" than "untoasted" because the latter feels like
it could also mean "detoasted". (And as I write this para, I'm
having a hard time wanting to upcase the words, which reinforces
my doubts about s/toast/TOAST/g.)

======
Kind Regards,
Peter Smith.
Fujitsu Australia

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.

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 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

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

Hi,

If I understand correctly, the summary is:
- Tom: +1 for "TOAST table", but changing all the combined forms is
maybe not worth the effort.
- DavidJ: Wants to uppercase TOAST only when it refers to 'technique';
lowercase otherwise.
- RobertT: The verbs should be lowercase (e.g. laser). Each-way bet re
David's technique idea.
- RobertH: Don't lowercase verbs, but instead try to rewrite these
differently where possible.

~~

This thread seems to have exposed a lot of different opinions. I guess
that's the reason why the docs/comments got to be how they are now --
e.g. Everybody wrote what they believe is correct, but their idea of
correct differs from the next person.

BTW, this thread was not created because of any particular confusion
it was causing (although I am sure there are some confusing examples
to be found). It was more just that during reviews I kept seeing there
was no consistent use of toast v TOAST even in the same file/function.
It was this inconsistency that was annoying and prompted this thread.

But, because of all the differing views expressed here I'm not sure
now how to proceed. Any ideas?

I think everyone would agree that inconsistency is bad, so it becomes
a question then what if anything should be done about it. My plan was
to just come up with some fixed rules for mechanical changes (e.g.
"Always say TOAST table" or whatever). I know that may not always
result in the perfect choice, but IMO having some simple/fixed rules
for a code monkey to apply might be more prudent than rules requiring
subjective interpretations (e.g. will two people ever agree what is a
'technique' and what is not?) which would end up not addressing
consistency issue. Also, I agree that just rewriting text would be the
best choice in some cases but probably there are many dozens of
candidates so getting consensus on all of those rewrites will be like
herding cats.

Meanwhile, I've moved this CF entry into the next commitfest, because
I don't see how this thread can get resolved by the end of the month.

======
Kind Regards,
Peter Smith.
Fujitsu Australia

On Sun, Mar 16, 2025 at 7:38 PM Peter Smith <smithpb2250@gmail.com> wrote:

If I understand correctly, the summary is:
- Tom: +1 for "TOAST table", but changing all the combined forms is
maybe not worth the effort.
- DavidJ: Wants to uppercase TOAST only when it refers to 'technique';
lowercase otherwise.
- RobertT: The verbs should be lowercase (e.g. laser). Each-way bet re
David's technique idea.
- RobertH: Don't lowercase verbs, but instead try to rewrite these
differently where possible.

I'm not sure I agree with this summary of my position. I'm against
TOASTed, TOAST-able, and un-TOASTed, and in fact it seems to me that
nobody else who has commented on this proposal likes those either. It
seems to me that the idea of upper-casting TOAST where it stands alone
as a separate word may have some support, although not everyone who
has commented wants to do it in every situation and nobody seems to
think it is super-important. But as far as I can see, nobody other
than you is a fan of doing it when a prefix or suffix has been added.
I don't mean to suggest that your opinion is unimportant, just that,
in this case, it doesn't seem to have attracted any support from
others.

So I would suggest that you either:

(1) drop this patch, or perhaps
(2) cut it down to something that just changes some or all usages of
TOAST without prefix or suffix and leaves everything else alone, or
perhaps
(3) do (2) but also add some rewording to (3a) avoid needing to use
prefixed or suffixed forms or (3b) to avoid using TOAST altogether.

I really don't think you're going to get consensus on capitalizing the
letters TOAST someplace in the middle of a word. I mean, there's
probably precedent both ways. You get tasered by the police, not
TASERed by the police; but I think you would write that you were
SMSing with a colleague rather than smsing with a colleague. But as
you say, "everybody wrote what they believe is correct," so there is
probably not going to be support for radically upending our existing
conventions, and deTOASTing is definitely a minority position. If you
really want to change something, getting rid of the few instances of
minority positions like that might be palatable, but something that
involves replacing a lot of the forms people chose with other forms
seems less likely to achieve consensus.

The alternative of just not worrying about it too much also seems to
have some merit. As you say, you weren't actually confused, just
irritated by the inconsistency; and spending effort on things that are
more irritating than serious is not always the right thing to do.

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

On Sun, 16 Mar 2025 at 19:38, Peter Smith <smithpb2250@gmail.com> wrote:

But, because of all the differing views expressed here I'm not sure
now how to proceed. Any ideas?

May I suggest that you start with a patch to Appendix J, section 6 to
codify whatever is decided?

https://www.postgresql.org/docs/current/docguide-style.html

This is made a bit awkward because right now the style guide only has one
subsection, relating to reference page organization. So essentially I'm
suggesting an entirely new subsection which could eventually cover things
like capitalization and which grammatical forms to prefer, and that you
start with the toast/TOAST rules. Once you have at least one rule agreed
and added to the style guide, then a patch to revise existing examples of
contrary usage would be in my opinion a more clear win than it is now.

The above makes more sense to me if there are other questions of this
general nature that could benefit from an explicit mention in a style
guide, even if this patch wouldn't do that. If this is the only question
like this, then it looks a bit weird to add a whole section just for it.
But I lean towards the idea that over time there might be a number of
decisions of this nature that ought to be made and followed consistently.

On Mon, Mar 17, 2025 at 1:50 PM Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Mar 16, 2025 at 7:38 PM Peter Smith <smithpb2250@gmail.com> wrote:

If I understand correctly, the summary is:
- Tom: +1 for "TOAST table", but changing all the combined forms is
maybe not worth the effort.
- DavidJ: Wants to uppercase TOAST only when it refers to 'technique';
lowercase otherwise.
- RobertT: The verbs should be lowercase (e.g. laser). Each-way bet re
David's technique idea.
- RobertH: Don't lowercase verbs, but instead try to rewrite these
differently where possible.

I'm not sure I agree with this summary of my position. I'm against
TOASTed, TOAST-able, and un-TOASTed, and in fact it seems to me that
nobody else who has commented on this proposal likes those either. It
seems to me that the idea of upper-casting TOAST where it stands alone
as a separate word may have some support, although not everyone who
has commented wants to do it in every situation and nobody seems to
think it is super-important. But as far as I can see, nobody other
than you is a fan of doing it when a prefix or suffix has been added.
I don't mean to suggest that your opinion is unimportant, just that,
in this case, it doesn't seem to have attracted any support from
others.

Sorry if I've misrepresented your position. And, just for the record,
I'm not "a fan of doing it [capitalizing] when a prefix or suffix has
been added". I know in earlier posts I may have suggested doing that,
but that was me trying to be consistent with usage on the docs page
[1]: https://www.postgresql.org/docs/17/storage-toast.html
related words.

So I would suggest that you either:

(1) drop this patch, or perhaps
(2) cut it down to something that just changes some or all usages of
TOAST without prefix or suffix and leaves everything else alone, or
perhaps
(3) do (2) but also add some rewording to (3a) avoid needing to use
prefixed or suffixed forms or (3b) to avoid using TOAST altogether.

I really don't think you're going to get consensus on capitalizing the
letters TOAST someplace in the middle of a word. I mean, there's
probably precedent both ways. You get tasered by the police, not
TASERed by the police; but I think you would write that you were
SMSing with a colleague rather than smsing with a colleague. But as
you say, "everybody wrote what they believe is correct," so there is
probably not going to be support for radically upending our existing
conventions, and deTOASTing is definitely a minority position. If you
really want to change something, getting rid of the few instances of
minority positions like that might be palatable, but something that
involves replacing a lot of the forms people chose with other forms
seems less likely to achieve consensus.

Thanks for your suggestions. At this point option (1) is looking most
attractive. Probably, I will just withdraw the CF entry soon unless
there is some new interest. Just chipping away fixing a few places
isn't going to achieve the consistency this thread was aiming for.

The alternative of just not worrying about it too much also seems to
have some merit. As you say, you weren't actually confused, just
irritated by the inconsistency; and spending effort on things that are
more irritating than serious is not always the right thing to do.

Yes, as I am learning.

======
[1]: https://www.postgresql.org/docs/17/storage-toast.html

Kind Regards,
Peter Smith.
Fujitsu Australia

As the original author of the TOAST I vote for TOAST being used as the
name/acronym of the feature, but toast in all other cases like as verb.

Best Regards, Jan

Jan Wieck <jan@wi3ck.info> writes:

As the original author of the TOAST I vote for TOAST being used as the
name/acronym of the feature, but toast in all other cases like as verb.

Well, if we're appealing to history ... I dug in the archives
and found that you seem to have invented the name here [1]/messages/by-id/m120C3U-0003kHC@orion.SAPserv.Hamburg.dsh.de:

Since we decided not to create a separate LONG datatype, and
not doing LONG attributes alone (compression at some point
too), I looked for some unique name for it - and found one.
The characters 'toast' did not show up on a case insensitive
grep over the entire CVS tree. Thus, I'll call it

tuple toaster

subsequently. I think there are enough similarities to a
toaster in this case. If you take a bread (tuple) and toast
some of the slices (attributes), anything can work as you
want and it will smell and taste delicious. In some cases,
slices might get burned (occationally hitting an indexed
value), taste bitter and it will stink.

BTW: The idea itself was stolen from toast/untoast, a GSM
voice data compression/decompression tool.

Note the lack of any upper case. Shortly later we reverse-engineered
an acronym for it [2]/messages/by-id/m120DHd-0003kLC@orion.SAPserv.Hamburg.dsh.de, with the winner being Tom Lockhart's

The Oversized-Attribute Storage Technique

So I'd say that the basis for upper-casing it at all is mighty
thin; it was not conceived as an acronym to begin with. We should
probably adjust our glossary entry for it to nod in the direction
of that GSM tool, if anyone can find a modern reference for that.

regards, tom lane

[1]: /messages/by-id/m120C3U-0003kHC@orion.SAPserv.Hamburg.dsh.de
[2]: /messages/by-id/m120DHd-0003kLC@orion.SAPserv.Hamburg.dsh.de

On 3/17/25 00:24, Tom Lane wrote:

Note the lack of any upper case. Shortly later we reverse-engineered
an acronym for it [2], with the winner being Tom Lockhart's

The Oversized-Attribute Storage Technique

Which made it into an acronym. Acronyms are typically capitalized to
distinguish them from ordinary words.

Best Regards, Jan

On 3/17/25 00:24, Tom Lane wrote:

Note the lack of any upper case. Shortly later we reverse-engineered
an acronym for it [2], with the winner being Tom Lockhart's

The Oversized-Attribute Storage Technique

I (very easily) found a reference to the GSM tool:
https://linux.die.net/man/1/toast

At the bottom, you're directed to write to Jutta at UT Berlin in case of
bugs. Searching for that you'll eventually arrive at
http://quut.com/berlin/toast.html
which points out that this is Jutta Degener, currently of Sunnyvale, CA:
https://quut.com/credits.p3

On 2025-Mar-17, Jan Wieck wrote:

Which made it into an acronym. Acronyms are typically capitalized to
distinguish them from ordinary words.

However, we do stop capitalizing acronyms once they get in common
enough. The example of LASER (originall acronym for "light
amplification by stimulated emission of radiation") was already
mentioned, but there's also RADAR ("radio detection and ranging"), which
is particularly useful in this discussion because its wikipedia page
says

The term radar has since entered English and other languages as
an anacronym, a common noun, losing all capitalization.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"I apologize for the confusion in my previous responses.
There appears to be an error." (ChatGPT)

On Sun, Mar 16, 2025 at 8:33 PM Peter Smith <smithpb2250@gmail.com> wrote:

Thanks for your suggestions. At this point option (1) is looking most
attractive. Probably, I will just withdraw the CF entry soon unless
there is some new interest. Just chipping away fixing a few places
isn't going to achieve the consistency this thread was aiming for.

I've moved this back to waiting on author pending a final decision.
Interested parties might still chime in but it doesn't seem like it is
actively looking for reviewers at this point.

David J.

Hi，
I think this point is of no significance at all. Besides, this is a
document that has been around for over ten years. Everyone has become
accustomed to this kind of expression. This is just a case of being full
but having nothing to do with anything.

On Sat, 12 Apr 2025 at 10:31, David G. Johnston <david.g.johnston@gmail.com>
wrote:

On 16.01.25 06:38, Peter Smith 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.

Hi, thanks for the reply.

How about I reduce the scope by only tackling the uncontroversial
stuff, and leave all those "combined forms" for another day?

Attached is the reduced patch for changes to the documentation.

committed

On Tue, Jul 1, 2025 at 6:29 PM Peter Eisentraut <peter@eisentraut.org> wrote:

On 16.01.25 06:38, Peter Smith 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.

Hi, thanks for the reply.

How about I reduce the scope by only tackling the uncontroversial
stuff, and leave all those "combined forms" for another day?

Attached is the reduced patch for changes to the documentation.

committed

Thanks for pushing!

Those were all (supposedly) uncontroversial changes for just the SGML docs.

Originally, I had planned to see if this 1st patch would be pushed,
and if so, then look at making all the same kinds of changes to the
code comments. But, given the debate/time to get this far, I'm
thinking it's not worth opening Pandora's box a 2nd time. Please let
me know if you think otherwise.

======
Kind Regards,
Peter Smith.
Fujitsu Australia