Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M234160=pgsql-hackers-arkari@postgresql.org>)
 id 1VNB9M-0007jS-4L
 for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Sep 2013 00:34:16 +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+M234160=pgsql-hackers-arkari@postgresql.org>)
 id 1VNB9L-0007Lw-Aa
 for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Sep 2013 00:34:15 +0000
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <maumau307@gmail.com>) id 1VNB9J-0007KE-KT
 for pgsql-hackers@postgresql.org; Sat, 21 Sep 2013 00:34:13 +0000
Received: from mail-pb0-x22c.google.com ([2607:f8b0:400e:c01::22c])
 by makus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <maumau307@gmail.com>)
 id 1VNB9G-0006YT-W5; Sat, 21 Sep 2013 00:34:13 +0000
Received: by mail-pb0-f44.google.com with SMTP id xa7so990461pbc.31
 for <multiple recipients>; Fri, 20 Sep 2013 17:34:10 -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=Oh4Z8+/q0SRBHtLSf47V3qo4bxV85hTy4v/MU5LNlWQ=;
 b=hl9TtliJFHpCWd+fuJDntVR/IohFT471K/HuWljGW0nuKVpxKv53jAPmmPdiJoRCmH
 oxaxuJ/RMkyTTwBxsYdsB5DbKUWIkJKzeuhzZDcXcbAHHgPiQaOYlRvYsS7OTI6Y9j7K
 xA9PlaLTm/pTNpq5fUio1igRkvR2BBWd1Q5YIZqjo+fi8QV2buD7N6IqmBHs5izgfzZv
 Vu2qsLpzGJSBLu2pwQenKFCqQLRdaHZ1hzS8C/sevjIeVbJU7uzzmyU/vE/PuqVsz2mt
 NnZGr6RMnN9K6Pg9ITdkKx8S1Z98bgQcixwlT+fJEt7U92zm6uxTwrQSkKQdTj+YjHCc
 lNFQ==
X-Received: by 10.66.142.230 with SMTP id rz6mr11702591pab.117.1379723650091;
 Fri, 20 Sep 2013 17:34:10 -0700 (PDT)
Received: from maumau (p6019-ipbfp211sizuokaden.shizuoka.ocn.ne.jp.
 [114.170.213.19])
 by mx.google.com with ESMTPSA id l8sm18383802pbl.22.1969.12.31.16.00.00
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Fri, 20 Sep 2013 17:34:09 -0700 (PDT)
Message-ID: <75E3DA50779B4FB79FB3DFC0211E8F8A@maumau>
From: "MauMau" <maumau307@gmail.com>
To: "Robert Haas" <robertmhaas@gmail.com>,
 "Tatsuo Ishii" <ishii@postgresql.org>
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: 
 <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>
 <CA+TgmoZEy=pt2B5D+nuPAib7KvhNoBgRGYRWnkS4pyrqfcdYHQ@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZEy=pt2B5D+nuPAib7KvhNoBgRGYRWnkS4pyrqfcdYHQ@mail.gmail.com>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Sat, 21 Sep 2013 09:36:20 +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: 0.6 (/)
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: "Robert Haas" <robertmhaas@gmail.com>
> On Thu, Sep 19, 2013 at 7:58 PM, Tatsuo Ishii <ishii@postgresql.org> 
> wrote:
>> 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.
>
> I think the point here is that, at least as I understand it, encoding
> conversion and sanitization happens at a very early stage right now,
> when we first receive the input from the client.  If the user sends a
> string of bytes as part of a query or bind placeholder that's not
> valid in the database encoding, it's going to error out before any
> type-specific code has an opportunity to get control.   Look at
> textin(), for example.  There's no encoding check there.  That means
> it's already been done at that point.  To make this work, someone's
> going to have to figure out what to do about *that*.  Until we have a
> sketch of what the design for that looks like, I don't see how we can
> credibly entertain more specific proposals.

OK, I see your point.  Let's consider that design.  I'll learn the code 
regarding this.  Does anybody, especially Tatsuo san, Tom san, Peter san, 
have any good idea?

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