Message-ID: <37B76474BB3149FD841373E12E355851@maumau>
From: "MauMau" <maumau307@gmail.com>
To: "Robert Haas" <robertmhaas@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>,
 "Boguk, Maksym" <maksymb@fast.au.fujitsu.com>,
 "Heikki Linnakangas" <hlinnakangas@vmware.com>,
 <pgsql-hackers@postgresql.org>
References: 
 <A756FAD7EDC2E24F8CAB7E2F3B5375E918E2D5B8@FALEX03.au.fjanz.com><522594E8.2050106@vmware.com><A756FAD7EDC2E24F8CAB7E2F3B5375E918F332A6@FALEX03.au.fjanz.com><904.1378304922@sss.pgh.pa.us><B1A7485194DE4FDAB8FA781AFB570079@maumau><CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com><B00EACB87A2441069B4EE4DEA6D9282A@maumau>
 <CA+TgmoaT-h5C25LXd1DgfyiW2t9K92eVdVcJHC_1We0JpJFqgg@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoaT-h5C25LXd1DgfyiW2t9K92eVdVcJHC_1We0JpJFqgg@mail.gmail.com>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Fri, 20 Sep 2013 07:42:19 +0900
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

From: "Robert Haas" <robertmhaas@gmail.com>
> That may be what's important to you, but it's not what's important to
> me.

National character types support may be important to some potential users of 
PostgreSQL and the popularity of PostgreSQL, not me.  That's why national 
character support is listed in the PostgreSQL TODO wiki.  We might be losing 
potential users just because their selection criteria includes national 
character support.


> I am not keen to introduce support for nchar and nvarchar as
> differently-named types with identical semantics.

Similar examples already exist:

- varchar and text: the only difference is the existence of explicit length 
limit
- numeric and decimal
- int and int4, smallint and int2, bigint and int8
- real/double precison and float

In addition, the SQL standard itself admits:

"The <key word>s NATIONAL CHARACTER are used to specify the character type 
with an implementation-
defined character set. Special syntax (N'string') is provided for 
representing literals in that character set.
...
"NATIONAL CHARACTER" is equivalent to the corresponding <character string 
type> with a specification
of "CHARACTER SET CSN", where "CSN" is an implementation-defined <character 
set name>."

"A <national character string literal> is equivalent to a <character string 
literal> with the "N" replaced by
"<introducer><character set specification>", where "<character set 
specification>" is an implementation-
defined <character set name>."


> And I think it's an
> even worse idea to introduce them now, making them work one way, and
> then later change the behavior in a backward-incompatible fashion.

I understand your feeling.  The concern about incompatibility can be 
eliminated by thinking the following way.  How about this?

- NCHAR can be used with any database encoding.

- At first, NCHAR is exactly the same as CHAR.  That is, 
"implementation-defined character set" described in the SQL standard is the 
database character set.

- In the future, the character set for NCHAR can be selected at database 
creation like Oracle's CREATE DATABAWSE .... NATIONAL CHARACTER SET 
AL16UTF16.  The default it the database set.


Could you tell me what kind of specification we should implement if we 
officially support national character types?

Regards
MauMau


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers