Re: TOAST versus toast

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TOAST versus toast
Date: 2025-03-16 23:38:19
Message-ID: CAHut+PsTc2TyA9A-NvZF3G_tp_Biv9nEWeVkEFjW9cz_ZE1DWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-03-16 23:39:49 Re: Dubious server log messages after pg_upgrade
Previous Message Tom Lane 2025-03-16 22:26:23 Re: pg_dump, pg_dumpall, pg_restore: Add --no-policies option