| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "Arulappan, Arul Shaji" <arul(at)fast(dot)au(dot)fujitsu(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal - Support for National Characters functionality |
| Date: | 2013-07-05 12:17:25 |
| Message-ID: | 51D6B955.8000502@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07/05/2013 02:12 AM, Arulappan, Arul Shaji wrote:
> - Support for UTF16 column encoding and representing NCHAR and
> NVARCHAR columns in UTF16 encoding in all databases.
>> Why do yo need UTF-16 as the database encoding? UTF-8 is already
> supported,
>> and any UTF-16 character can be represented in UTF-8 as far as I know.
>>
> Yes, that's correct. However there are advantages in using UTF-16
> encoding for those characters that are always going to take atleast
> two-bytes to represent.
>
Any suggestion to store data in utf-16 is likely to be a complete
non-starter. I suggest you research our previously stated requirements
for server side encodings.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2013-07-05 12:47:22 | Re: LDAP: bugfix and deprecated OpenLDAP API |
| Previous Message | Andrew Dunstan | 2013-07-05 12:08:06 | Re: [9.3 bug fix] ECPG does not escape backslashes |