From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Language support of postgresql |
Date: | 2017-05-02 18:55:57 |
Message-ID: | 1a9fe69c-26b6-9935-0bcd-c7c1b6661e45@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/2/2017 11:41 AM, Tom Lane wrote:
> John R Pierce<pierce(at)hogranch(dot)com> writes:
>> I thought Postgres supported client_encodings of BIG5, GB18030, and GBK,
>> all of which can be stored in the server using either UTF8 or
>> MULE_INTERNAL (MultiLingual EMACS) encodings for internal storage ?
> Hm, there's MULE<=>BIG5 converters but I don't see any for GBK or
> GB18030. Also, it looks like the MULE<=>BIG5 converters do some
> re-encoding, so it's not clear to me whether they're lossless,
> which I assume is the concern driving this request.
I based my statement on misreading the tables on here,
https://www.postgresql.org/docs/current/static/multibyte.html but, now I
see, MULE only supports big5 and EUC_CN.
My limited readings earlier about BIG5 suggested its a mess of
conflicting extensions, E-TEN and others, and the GB* stuff wasn't much
better.
Anyways, it seems to me like UTF8 is the correct server encoding for
most all uses.
--
john r pierce, recycling bits in santa cruz
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2017-05-02 19:45:26 | Re: [GENERAL] Column rename in an extension update script |
Previous Message | Tom Lane | 2017-05-02 18:41:20 | Re: Language support of postgresql |