Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M234156=pgsql-hackers-arkari@postgresql.org>)
 id 1VNAAt-0005EX-FJ
 for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2013 23:31:47 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M234156=pgsql-hackers-arkari@postgresql.org>)
 id 1VNAAs-0000Va-LN
 for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2013 23:31:46 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <maumau307@gmail.com>) id 1VNAAq-0000VP-62
 for pgsql-hackers@postgresql.org; Fri, 20 Sep 2013 23:31:44 +0000
Received: from mail-pa0-x231.google.com ([2607:f8b0:400e:c03::231])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <maumau307@gmail.com>)
 id 1VNAAi-0001Bn-St; Fri, 20 Sep 2013 23:31:43 +0000
Received: by mail-pa0-f49.google.com with SMTP id ld10so1290565pab.22
 for <multiple recipients>; Fri, 20 Sep 2013 16:31:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=message-id:from:to:cc:references:in-reply-to:subject:date
 :mime-version:content-type:content-transfer-encoding;
 bh=wV05Hoxqqqs/OMbluvLb3o9PX1WAZx4sabBOxrwPqcU=;
 b=DDDaz3wH5SUdekG4C5saIXocbT7OpfwGPJv9MukS0cFRteS5VdVwgJoPhk2FlPpTiH
 WkelzWnqaYT19iqVFSHV5NGDcz76bjfQqLXE4mKqJG73/Ntz4HbV4IASdbvJlGrB64xs
 zg6oIq6s9Yv9Jb7iHivIt9XLPSgBTYxU19HFKrF3OVYmRrsf7m6YtP7nK9UoBzEqlvQE
 Y22cLjFNgYcfKvw02FZr+BlwN8kG3u53ejvjy2Yb2tg6k91D4LzP6wk4u0AdgRQc2dln
 MeoE+5rWChokxCW49hKnQvfCtkK63YQ3d8zwtwI05BZGL3JUytP+UlrLfUzKtaxqMBlv
 3Hag==
X-Received: by 10.66.249.134 with SMTP id yu6mr11403768pac.37.1379719894587;
 Fri, 20 Sep 2013 16:31:34 -0700 (PDT)
Received: from maumau (p6019-ipbfp211sizuokaden.shizuoka.ocn.ne.jp.
 [114.170.213.19])
 by mx.google.com with ESMTPSA id fy4sm18231354pbb.1.1969.12.31.16.00.00
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Fri, 20 Sep 2013 16:31:33 -0700 (PDT)
Message-ID: <225725531CAD4DA6AAED8F4F3F8EFF94@maumau>
From: "MauMau" <maumau307@gmail.com>
To: <robertmhaas@gmail.com>,
	"Tatsuo Ishii" <ishii@postgresql.org>
Cc: <tgl@sss.pgh.pa.us>, <maksymb@fast.au.fujitsu.com>,
 <hlinnakangas@vmware.com>, <pgsql-hackers@postgresql.org>
References: 
 <904.1378304922@sss.pgh.pa.us><B1A7485194DE4FDAB8FA781AFB570079@maumau><CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com>
 <20130920.085853.1628917054830864151.t-ishii@sraoss.co.jp>
In-Reply-To: <20130920.085853.1628917054830864151.t-ishii@sraoss.co.jp>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Sat, 21 Sep 2013 08:33:28 +0900
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18197
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463
X-Pg-Spam-Score: -1.3 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

From: "Tatsuo Ishii" <ishii@postgresql.org>
> What about limiting to use NCHAR with a database which has same
> encoding or "compatible" encoding (on which the encoding conversion is
> defined)? This way, NCHAR text can be automatically converted from
> NCHAR to the database encoding in the server side thus we can treat
> NCHAR exactly same as CHAR afterward.  I suppose what encoding is used
> for NCHAR should be defined in initdb time or creation of the database
> (if we allow this, we need to add a new column to know what encoding
> is used for NCHAR).
>
> For example, "CREATE TABLE t1(t NCHAR(10))" will succeed if NCHAR is
> UTF-8 and database encoding is UTF-8. Even succeed if NCHAR is
> SHIFT-JIS and database encoding is UTF-8 because there is a conversion
> between UTF-8 and SHIFT-JIS. However will not succeed if NCHAR is
> SHIFT-JIS and database encoding is ISO-8859-1 because there's no
> conversion between them.

Thanks for the idea, it sounds flexible for wider use.  Your cooperation 
would be much appreciated to devise implementation with as little code as 
possible.

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