Message-ID: <A33C037F0BB04126AD5F7CEE69B8F619@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><37B76474BB3149FD841373E12E355851@maumau>
 <CA+TgmoZENYsQ5BwsjKz+SU8e1+JjtHNLqz4q9=FYn7n_dHBw_w@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZENYsQ5BwsjKz+SU8e1+JjtHNLqz4q9=FYn7n_dHBw_w@mail.gmail.com>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Sat, 21 Sep 2013 09:32:27 +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>
> I don't think that you'll be able to
> get consensus around that path on this mailing list.

> I agree that the fact we have both varchar and text feels like a wart.

Is that right?  I don't feel varchar/text case is a wart.  I think text was 
introduced for a positive reason to ease migration from other DBMSs.  The 
manual says:

http://www.postgresql.org/docs/current/static/datatype-character.html

"Although the type text is not in the SQL standard, several other SQL 
database management systems have it as well."

And isn't EnterpriseDB doing similar things for Oracle compatibility, 
although I'm not sure about the details?  Could you share your idea why we 
won't get consensus?


>> 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.
>
> Hmm.  So under that design, a database could support up to a total of
> two character sets, the one that you get when you say 'foo' and the
> other one that you get when you say n'foo'.
>
> I guess we could do that, but it seems a bit limited.  If we're going
> to go to the trouble of supporting multiple character sets, why not
> support an arbitrary number instead of just two?

I agree with you about the arbitrary number.  Tatsuo san gave us a good 
suggestion.  Let's consider how to implement that.

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