Re: bulk typos

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: bulk typos
Дата
Msg-id 20201031020801.GD3080@telsasoft.com
обсуждение исходный текст
Ответ на Re: bulk typos  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: bulk typos  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Sun, Oct 25, 2020 at 02:48:49PM -0500, Justin Pryzby wrote:
> 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.

I've added a few more, but still not sure about these two.

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Stats collector's idx_blks_hit value is highly misleading in practice
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Collation versioning