>-Original Message-
>From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>ow...@postgresql.org] On Behalf Of MauMau
>
>Hello,
>
>I think it would be nice for PostgreSQL to support national character
types
>largely because it should ease migration from other DBMSs.
>
>[Reasons
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>
> Alvaro Herrera writes:
> > Also, as far as I understand what we want to control here is the
> > encoding that the strings are in (the mapping of bytes to
characters),
> > not the collation (the way a set of strings are ordered). So it
> > doesn't
> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
>
> Boguk, Maksym escribió:
>
> > I think I give a wrong description there... it will be not GUC but
> > GUC-type value which will be initialized during CREATE DATABASE and
> > will be read only after, very similar to the lc_collate.
> > So
> -Original Message-
> From: Tatsuo Ishii [mailto:is...@postgresql.org]
>
>
> Also I don't understand why you need UTF-16 support as a database
encoding
> because UTF-8 and UTF-16 are logically equivalent, they are just
different
> represention (encoding) of Unicode. That means if we alre
>
> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
wrote:
> > Yes, what I know almost all use utf8 without problems. Long time I
> > didn't see any request for multi encoding support.
>
> Well, not *everything* can be represented as UTF-8; I think this is
> particularly an issue with Asian langua
> -Original Message-
> From: Claudio Freire [mailto:klaussfre...@gmail.com]
> Sent: Friday, 5 July 2013 3:41 PM
> To: Tatsuo Ishii
> Cc: Arulappan, Arul Shaji; PostgreSQL-Dev
> Subject: Re: [HACKERS] Proposal - Support for National Characters
> functionality
>
&g
Ishii san,
Thank you for your positive and early response.
> -Original Message-
> From: Tatsuo Ishii [mailto:is...@postgresql.org]
> Sent: Friday, 5 July 2013 3:02 PM
> To: Arulappan, Arul Shaji
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Proposal - Su
This is a proposal to implement functionalities for the handling of
National Characters.
[Introduction]
The aim of this proposal is to eventually have a way to represent
'National Characters' in a uniform way, even in non-UTF8 encoded
databases. Many of our customers in the Asian region who are