Horton

Re: GB18030-2022 Support in PostgreSQL

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: John Naylor <johncnaylorls@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>
Date: 2025-08-11T09:25:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Generate EUC_CN mappings from gb18030-2022.ucm

  2. Update GB18030 encoding from version 2000 to 2022

  3. Generate GB18030 mappings from the Unicode Consortium's UCM file

> That would match my expectation. In case it wasn't clear before, my
> preference is to split this patch into two patches: First convert to
> .ucm, then update to 2022 revision. Then the small diff will be
> obvious to everyone who looks at the second commit.

Sure I can split the patch into two. The patch only changes the .xml file to .ucm file and updating the perl script. As a result, map files should not be changed.

Then the second patch will update the ucm file, so that the second patch should be small, contains only ucm changes and map file changes.

One thing to confirm with you. To archive that, we will rename the ucm file as gb18030.ucm without suffix of “-2000” and “-2022”, otherwise git won’t be able to show the diff. Is that what you meant?


> 
> Thanks for clarifying -- by saying "retained in the patch", the commit
> message implied to me that the patch added something not in the
> upstream file.
> 
I will update the commit message in the new patch.


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