Assorted typo fixes

On Thu, Dec 28, 2023 at 3:21 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:

Hi folks,

I was playing around with the `typos` tool
(https://github.com/crate-ci/typos), and thought I'd run it on the
posgres repo for fun. After a bit of tweaking to get rid of most false
positives (see separately attached .typos.toml file), it came up with a
useful set of suggestions, some of which I applied verbatim, others
which needed a bit more rewording.

Attached is a series of patches. The first one are what I consider
obvious, unambiguous fixes to code comments. The subsequent ones are
fixes for actual code (variable, function, type names) and docs, one
patch per class of typo. As far as I can tell, none of the code changes
(except the ECPG one, see below) affect anything exported, so this
should not cause any compatibility issues for extensions.

The ECPG change affects the generated C code, but from my reading of the
callers in descriptor.c and ecpg.trailer, any code that would have
caused it to encounter the affected enum value would fail to compile, so
either the case is not possible, or nobody actually uses whatever syntax
is affected (I don't know enough about ECPG to tell without spending far
too much time digging in the code).

I was reviewing the Patch and came across a minor issue that the Patch
does not apply on the current Head. Please provide the updated version
of the patch. Also, I found one typo:
0008-ecpg-fix-typo-in-get_dtype-return-value-for-ECPGd_co.patch
All the other enum values return a string mathing the enum label, but
this has had a trailing r since the function was added in commit
339a5bbfb17ecd171ebe076c5bf016c4e66e2c0a

Here 'mathing' should be 'matching'.

Thanks and Regards,
Shubham Khanna.

Shubham Khanna <khannashubham1197@gmail.com> writes:

I was reviewing the Patch and came across a minor issue that the Patch
does not apply on the current Head. Please provide the updated version
of the patch.

Thanks for the heads-up. Commit 5ccb3bb13dcbedc30d015fc06d306d5106701e16
removed one of the instances of "data struture" fixed by the patch.

Rebased patch set attached. I also squashed the check_decls.m4 change
into the main comment typos commit.

Also, I found one typo:
0008-ecpg-fix-typo-in-get_dtype-return-value-for-ECPGd_co.patch All
the other enum values return a string mathing the enum label, but this
has had a trailing r since the function was added in commit
339a5bbfb17ecd171ebe076c5bf016c4e66e2c0a

Here 'mathing' should be 'matching'.

Thanks. I've fixed the commit message (and elaborated it a bit more why
I think it's a valid and safe fix).

Thanks and Regards,
Shubham Khanna.

- ilmari

On Tue, Jan 2, 2024 at 4:35 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:

Shubham Khanna <khannashubham1197@gmail.com> writes:

I was reviewing the Patch and came across a minor issue that the Patch
does not apply on the current Head. Please provide the updated version
of the patch.

Thanks for the heads-up. Commit 5ccb3bb13dcbedc30d015fc06d306d5106701e16
removed one of the instances of "data struture" fixed by the patch.

Rebased patch set attached. I also squashed the check_decls.m4 change
into the main comment typos commit.

Also, I found one typo:
0008-ecpg-fix-typo-in-get_dtype-return-value-for-ECPGd_co.patch All
the other enum values return a string mathing the enum label, but this
has had a trailing r since the function was added in commit
339a5bbfb17ecd171ebe076c5bf016c4e66e2c0a

Here 'mathing' should be 'matching'.

Thanks. I've fixed the commit message (and elaborated it a bit more why
I think it's a valid and safe fix).

I have reviewed the Rebased version of the Patch and it looks fine to me.

Thanks and Regards,
Shubham Khanna.

On Mon, Jan 1, 2024 at 6:05 PM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:

Thanks. I've fixed the commit message (and elaborated it a bit more why
I think it's a valid and safe fix).

Regarding 0001:

- AIUI, check_decls.m4 is copied from an upstream project, so I don't
think we should tinker with it.
- I'm not convinced by encrypter->encryptor
- I'm not convinced by multidimension-aware->multidimensional-aware
- I'm not convinced by cachable->cacheable
- You corrected restorting to restarting, but I'm wondering if Andres
intended restoring?

Committed the rest of 0001.

0002-0005 look OK to me, so I committed those as well.

With regard to 0006, we typically use indexes rather than indices as
the plural of "index", although exceptions exist.

I haven't looked at the rest.

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

On Tue, Jan 02, 2024 at 12:34:20PM -0500, Robert Haas wrote:

0002-0005 look OK to me, so I committed those as well.

Cool, thanks.

With regard to 0006, we typically use indexes rather than indices as
the plural of "index", although exceptions exist.

I haven't looked at the rest.

I got that on a local branch, then got drifted away. I have grouped
0007~0009 together (0007 was on me), and applied them on HEAD.

0010 is indeed the "correct" plural form for vertex I've known but
"vertexes" is not wrong either. Perhaps that's worth changing on
consistency grounds?

    8)</literal>, must be identical.  It doesn't matter which representation
    you choose to be the canonical one, so long as two equivalent values with
-   different formattings are always mapped to the same value with the same
+   different formatting are always mapped to the same value with the same
    formatting.

I am not sure about this one in 0011 though.. It also feels like this
could be reworded completely.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

0010 is indeed the "correct" plural form for vertex I've known but
"vertexes" is not wrong either. Perhaps that's worth changing on
consistency grounds?

Yeah. A quick grep shows that we have 16 uses of "vertices" and
only this one of "vertexes". It's not really wrong, but +1 for
making it match the others.

8)</literal>, must be identical.  It doesn't matter which representation
you choose to be the canonical one, so long as two equivalent values with
-   different formattings are always mapped to the same value with the same
+   different formatting are always mapped to the same value with the same
formatting.

I am not sure about this one in 0011 though.. It also feels like this
could be reworded completely.

I'd leave this alone, it's not wrong either. If you want to propose
a complete rewording, do so; but that's not "misspelling" territory.

regards, tom lane

Robert Haas <robertmhaas@gmail.com> writes:

On Mon, Jan 1, 2024 at 6:05 PM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:

Thanks. I've fixed the commit message (and elaborated it a bit more why
I think it's a valid and safe fix).

Regarding 0001:

- AIUI, check_decls.m4 is copied from an upstream project, so I don't
think we should tinker with it.

It contains modified versions of a few macros from Autoconf's
general.m4¹, specifically _AC_UNDECLARED_WARNING (since renamed to
_AC_UNDECLARED_BUILTIN upstream) and _AC_CHECK_DECL_BODY. That has
since been updated² to spell François' name correctly, so I think we
should follow suit (and maybe also check if our override is even still
necessary).

[1]: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=history;f=lib/autoconf/general.m4;hb=HEAD
[2]: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=8a228e9d58363ad3ebdb89a05bd77568d1d863b7

- I'm not convinced by encrypter->encryptor
- I'm not convinced by multidimension-aware->multidimensional-aware

I don't feel particularly strongy about these.

- I'm not convinced by cachable->cacheable

If nothing else, consistency. There are 13 occurrences of "cacheable"
and only three of "cachable" in the tree.

- You corrected restorting to restarting, but I'm wondering if Andres
intended restoring?

Yeah, re-reading the sentence that's clearly meant to be "restoring".

Committed the rest of 0001.

0002-0005 look OK to me, so I committed those as well.

Thanks!

With regard to 0006, we typically use indexes rather than indices as
the plural of "index", although exceptions exist.

We (mostly) use indexes when referring to database indexes (as in btree,
gist, etc.), but indices when referring to offsets in arrays, which is
what this variable is about.

- ilmari

On Wed, Jan 03, 2024 at 12:56:58AM -0500, Tom Lane wrote:

Yeah. A quick grep shows that we have 16 uses of "vertices" and
only this one of "vertexes". It's not really wrong, but +1 for
making it match the others.

Applied this one as 793ecff7df80 on HEAD.

I'd leave this alone, it's not wrong either. If you want to propose
a complete rewording, do so; but that's not "misspelling" territory.

I don't have a better idea in my mind now, so I'm OK to leave that be.
--
Michael