Re: speed up unicode normalization quick check
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, John Naylor <john.naylor@enterprisedb.com>, Mark Dilger <mark.dilger@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-19T06:57:28Z
Lists: pgsql-hackers
On Mon, Oct 19, 2020 at 08:15:56AM +0200, Peter Eisentraut 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
Hmm. Giving up on the left space padding would make the table harder
to read because the elements would not be aligned anymore across
multiple lines, and I'd rather keep 8 elements per lines as we do now.
This is generated by this part in PerfectHash.pm, where we apply a
at most 7 spaces of padding to all the members, except the first one
of a line that uses 6 spaces at most with two tabs:
for (my $i = 0; $i < $nhash; $i++)
{
$f .= sprintf "%s%6d,%s",
($i % 8 == 0 ? "\t\t" : " "),
$hashtab[$i],
($i % 8 == 7 ? "\n" : "");
}
Could we consider this stuff as a special case in .gitattributes
instead?
--
Michael
Commits
-
Review format of code generated by PerfectHash.pm
- 19ae53c92d5f 14.0 landed
-
Fix compilation warning in unicode_norm.c
- e578c17d8166 14.0 landed
-
Use perfect hash for NFC and NFKC Unicode Normalization quick check
- 80f8eb79e24d 14.0 landed
-
Improve set of candidate multipliers for perfect hash function generation
- 2a7316458164 14.0 landed
-
Further improve pgindent's list of file exclusions.
- 74d4608f506b 14.0 cited