| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Subject: | Re: bulk typos |
| Date: | 2020-11-02 06:22:03 |
| Message-ID: | 20201102062203.GA15770@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 30, 2020 at 09:08:01PM -0500, Justin Pryzby wrote:
> On Sun, Oct 25, 2020 at 02:48:49PM -0500, Justin Pryzby wrote:
>> 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.
What you have sent for xml.c is a clear improvement, but I am not sure
if that's the best we can do. So I have left this part out, and
applied the rest.
PS: I am also quite fond of "unbetimes".
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Nancarrow | 2020-11-02 06:39:00 | Re: Parallel INSERT (INTO ... SELECT ...) |
| Previous Message | Erik Rijkers | 2020-11-02 06:15:28 | Re: Additional Chapter for Tutorial |