Re: bulk typos - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: bulk typos
Date
Msg-id 20201025194849.GM9241@telsasoft.com
Whole thread Raw
In response to bulk typos  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: bulk typos
Re: bulk typos
List pgsql-hackers
On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
> I needed another distraction so bulk-checked for typos, limited to comments in
> *.[ch].
> 
> I'm not passionate about this, but it serves the purpose of reducing the
> overhead of fixing them individually.

I happened across this old patch, so ran this again to find new typos.

There's a few that I don't know how best to fix.

Heikki, do you remember what this means ?
+++ b/src/backend/catalog/storage.c
+ * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear
+ * unbetimes.  It'd probably be OK to keep it in TopTransactionContext,
+ * but I'm being paranoid.

Pavel, I can't understand this one.
I guess s/producement/producing/ is too simple of a fix.
Please check my proposed language.
+XmlTableFetchRow(TableFuncScanState *state)
+        * XmlTable returns table - set of composite values. The error context, is
+        * used for producement more values, between two calls, there can be
+        * created and used another libxml2 error context. ...

Surafel, this typo existed twice in the original commit (357889eb1).
One instance was removed by Tom in 35cb574aa.  Should we simply fix the typo,
or borrow Julien/Tom's lanuage?
+       * Tuple at limit is needed for comparation in subsequent
+       * execution to detect ties.

Attachment

pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: Commitfest manager 2020-11
Next
From: Heikki Linnakangas
Date:
Subject: Re: bulk typos