Re: GB18030-2022 Support in PostgreSQL
От | John Naylor |
---|---|
Тема | Re: GB18030-2022 Support in PostgreSQL |
Дата | |
Msg-id | CANWCAZYM7TqW7u+OAU3WUy+u3f04ZtJ7gEXOMXMvUgc=ALA2Qw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GB18030-2022 Support in PostgreSQL (Chao Li <li.evan.chao@gmail.com>) |
Список | pgsql-hackers |
On Tue, Aug 5, 2025 at 1:22 PM Chao Li <li.evan.chao@gmail.com> wrote: > > 2025年8月4日 21:51,Tom Lane <tgl@sss.pgh.pa.us> wrote: > > So on the whole I'd lean a bit towards just redefining GB18030 as > meaning the new standard. The fact that we don't support it as a > server-side encoding perhaps makes that idea more tenable than it > would be if the encoding governed the interpretation of our own > stored data. > I agree with Tom that we may just redefine GB18030 to comply with the 2022 standard. > > As John Naylor pointed, 2022 is not backward compatible, that is true. However, I went through all the incompatible changes,those are all characters rarely used. If that's the case than redefining is probably okay. > One use case I am thinking is that, say a database uses default encoding (UTF-8) and ICU locale provider. As ICU startedto support GB180303-2022 since version 73.1. ICU locales can only be used with sever-side encodings. > At the time when the new version is released, if some third party migration tools are known working fine, the release notemay recommend the tools. I highly doubt such a large hammer will be necessary. Whatever advice we give for discovery and conversion of affected text is our responsibility and can be in the form of example queries. -- John Naylor Amazon Web Services
В списке pgsql-hackers по дате отправления: