Re: GB18030-2022 Support in PostgreSQL

We split a patch into multiple patches, it's customary include all of
them, since that process may result in unwelcome artifacts to sort
out. (When the first step has architectural questions or change in
behavior, we may treat it as independent, possibly with a separate
thread, but that's not the case here.) 

Thanks for the explanation. I thought to make the second patch only after the first patch is pushed. I am new to PostgreSQL contribution, your guidance is very helpful for my future work.

Now I attach the both patch files.

For the second patch, I have tested it manually again. And "make check" test passed.

-# The lines we care about in the source file look like
+# The lines we care about in the source file look like:

These are spurious changes, which we try to avoid.

Updated.

- next if (!m/<a u="([0-9A-F]+)" b="([0-9A-F ]+)"/);

+ if (/^<U([0-9A-Fa-f]+)>\s+((?:\\x[0-9A-Fa-f]{2})+)\s*\|(\d+)/) {

This change in style caused extra whitespace-only churn. That obscures
what the actual changes are.

Updated.

+ # Match lines like: <UXXXX> \xYY[\xYY...] |n, and use only (|0) mappings

This is missing an explanation of why we skip non-zero mappings.
Code-wise, this only matters for the output in the follow-on patch for
2022, but one of these patches needs to include a brief explanation. I
did not like the detailed description that was present in one of the
earlier 2022 patches that told how many characters were flagged a
certain way -- that's irrelevant detail and will likely get out of
date in some future version anyway.

Okay, I kept a neat version of comment now.

+# and n is a flag indicating the type of mapping having
+# a single value of 0.

This seems weird when combined with the logic to filter out non-zero
mappings. We need to think about when and where to show relevant
information.

Updated the comment.

+ next if ($flag ne '0'); # non-0 flags

This comment is just repeating what the code is doing, and it's very
obvious what it's doing.

Removed the useless comment.

BTW, it sounds like your proposed Makefile changes are needed for the
follow-on patch with .map changes to work at all, is that right?

https://www.postgresql.org/message-id/1CA8625F-AA41-4ED2-B60F-E28AC71F37DC@highgo.com

I think that patch could be separate, because the makefile changes are generic to all map files. The current GB18030 patch doesn't depend on that makefile patch at all. The makefile patch just makes build a little bit easier upon map file changes.

Best regards,

--

Chao Li (Evan)
--------------------
HighGo Software Co., Ltd.
https://www.highgo.com/