Re: GB18030-2022 Support in PostgreSQL - Mailing list pgsql-hackers

From John Naylor
Subject Re: GB18030-2022 Support in PostgreSQL
Date
Msg-id CANWCAZY=6qq3obTNyUXq3gVa2an8mrC4c4SoDSi44NB9T0osOw@mail.gmail.com
Whole thread Raw
In response to Re: GB18030-2022 Support in PostgreSQL  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: GB18030-2022 Support in PostgreSQL
List pgsql-hackers
On Mon, Aug 11, 2025 at 3:22 PM Chao Li <li.evan.chao@gmail.com> wrote:

Hi,

For future reference, please don't quote my entire message below yours
-- it clutters the archives and also removes context.

> Yes, I did a diff between 2000.ucm and 2022.ucm when I worked on the patch. The diff between 2000.ucm and 2022.ucm
arequite small: 

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.

> For your question:
>
> "9 characters are no longer required by the new standard, but are
> retained in this patch for compatibility"
>
> How is that done?
>
>
> The 9 mappings are not changed between 2000.ucm and 2022.ucm. For example, GB18030 code 0xFD9C is one of the 9
not-requiredcode, but the mapping: 
>
> <UF92C> \xFD\x9C |0
>
> Still appears in 2022.ucm, so that this character is retained.

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.

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication
Next
From: Chao Li
Date:
Subject: Re: GB18030-2022 Support in PostgreSQL