Re: UTF8 national character data type support WIP patch and list of open issues. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: UTF8 national character data type support WIP patch and list of open issues.
Date
Msg-id CA+TgmoYdsztyG4ML=N69rj2q2XTTjogE38aFtXJxrpyqS9WLjA@mail.gmail.com
Whole thread Raw
In response to Re: UTF8 national character data type support WIP patch and list of open issues.  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: UTF8 national character data type support WIP patch and list of open issues.  ("MauMau" <maumau307@gmail.com>)
List pgsql-hackers
On Tue, Nov 5, 2013 at 5:15 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 11/5/13, 1:04 AM, Arulappan, Arul Shaji wrote:
>> Implements NCHAR/NVARCHAR as distinct data types, not as synonyms
>
> If, per SQL standard, NCHAR(x) is equivalent to CHAR(x) CHARACTER SET
> "cs", then for some "cs", NCHAR(x) must be the same as CHAR(x).
> Therefore, an implementation as separate data types is wrong.

Interesting.

Since the point doesn't seem to be getting through, let me try to be
more clear: we're not going to accept any form of this patch.  A patch
that makes some progress toward actually coping with multiple
encodings in the same database would be very much worth considering,
but adding compatible syntax with incompatible semantics is not of
interest to the PostgreSQL project.  We have had this debate on many
other topics in the past and will no doubt have it again in the
future, but the outcome is always the same.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Row-security writer-side checks proposal
Next
From: Albe Laurenz
Date:
Subject: Re: FDW: possible resjunk columns in AddForeignUpdateTargets