| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com>, JiaoShuntian <jiaoshuntian(at)highgo(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: GB18030-2022 Support in PostgreSQL |
| Date: | 2025-08-04 12:33:00 |
| Message-ID: | b423775a-9e11-4539-99da-adb98c79c55f@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-08-04 Mo 6:35 AM, John Naylor wrote:
> On Mon, Aug 4, 2025 at 3:08 PM JiaoShuntian <jiaoshuntian(at)highgo(dot)com> wrote:
>> I noticed that PostgreSQL currently supports GB18030 encoding based on the older GB18030-2000 standard (as seen in commits like extend GB18030 conversion). However, China has since updated its mandatory character set standard to GB18030-2022, which includes additional characters and stricter compliance requirements.GB18030-2022 is now the official standard in China, and ensuring PostgreSQL’s full compliance would be beneficial for users in Chinese-speaking regions.
> This is a non-backwards-compatible change:
>
> https://www.unicode.org/L2/L2022/22274-disruptive-changes.pdf
> https://www.unicode.org/L2/L2023/23003r-gb18030-recommendations.pdf
>
> There is a risk of breaking applications, although only a few dozen
> mappings changed. If it were added as a separate encoding, users could
> opt in.
>
That makes sense ... naming the new encoding so as to avoid confusion
might be a challenge.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2025-08-04 12:57:47 | Re: implement CAST(expr AS type FORMAT 'template') |
| Previous Message | vignesh C | 2025-08-04 12:32:13 | Re: Dropping publication breaks logical replication |