| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: speed up unicode normalization quick check |
| Date: | 2020-10-19 14:15:48 |
| Message-ID: | CAFBsxsGfJcFBMayaqHvRZ1izRZEoSY=Xy646r5A792uRYAq+bg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 19, 2020 at 2:16 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 2020-10-12 13:36, Michael Paquier wrote:
> > On Mon, Oct 12, 2020 at 03:39:51PM +0900, Masahiko Sawada wrote:
> >> Yes, this patch resolves the problem.
> >
> > Okay, applied then.
>
> Could you adjust the generation script so that the resulting header file
> passes the git whitespace check? Check the output of
>
> git show --check 80f8eb79e24d9b7963eaf17ce846667e2c6b6e6f
>
My git manual says:
"By default, trailing
whitespaces (including lines that consist solely of
whitespaces) and a space character that is immediately
followed by a tab character inside the initial indent of the
line are considered whitespace errors."
The above would mean we should have errors for every function whose
parameters are lined with the opening paren, so I don't see why it would
fire in this case. Is the manual backwards?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pierre Giraud | 2020-10-19 14:17:47 | Re: [PATCH] Add extra statistics to explain for Nested Loop |
| Previous Message | Dilip Kumar | 2020-10-19 14:10:49 | Is Recovery actually paused? |