Thread: Re: TOAST versus toast
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 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
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