Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M234223=pgsql-hackers-arkari@postgresql.org>)
 id 1VNzz6-0002OB-Mg
 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Sep 2013 06:51:05 +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+M234223=pgsql-hackers-arkari@postgresql.org>)
 id 1VNzz6-00088k-6L
 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Sep 2013 06:51:04 +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 1VNzz4-00088c-S7
 for pgsql-hackers@postgresql.org; Mon, 23 Sep 2013 06:51:03 +0000
Received: from mail-pd0-x234.google.com ([2607:f8b0:400e:c02::234])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <maumau307@gmail.com>)
 id 1VNzz2-0000Ni-H8; Mon, 23 Sep 2013 06:51:02 +0000
Received: by mail-pd0-f180.google.com with SMTP id y10so2822012pdj.25
 for <multiple recipients>; Sun, 22 Sep 2013 23:50:57 -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=eqPsVTQZpMypkhEVy4EMYayUPweSsrxQF7wO2+NetnM=;
 b=wwQm6SkAGt6O4FD90ZVtFV2m8FuZ7131v342ihRRtlt/Dn9dDmXJyVlU7nDrc+JSXq
 17zCHxp5GnFVFZcF42ObDa7+Y5/4mkcpaBfPAXLs5oPO67R2tJ0PEcU6dy5WchRwLNwP
 xFFGovf+JZ6DMpjA9et0xCh0HCS89Yk8BOCMg7IS1hyFrRP6wndPCSfs/6EIlMTZi3ym
 SBtOF3pFPSzDLXiDovs9Xluc0HRD6kJL1IPbKGqHIg5k2Qy4PCzZAahbVk6nTT7lFu2p
 +znvl4YyyV0OCrcLO61Z+2wjbeulcMAzWs24ExGP73957nAGpEnznxQCJv6dQ7wMZFN+
 bcfA==
X-Received: by 10.68.255.36 with SMTP id an4mr1201189pbd.154.1379919057282;
 Sun, 22 Sep 2013 23:50:57 -0700 (PDT)
Received: from maumau (p6019-ipbfp211sizuokaden.shizuoka.ocn.ne.jp.
 [114.170.213.19])
 by mx.google.com with ESMTPSA id ia5sm31941742pbc.42.1969.12.31.16.00.00
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Sun, 22 Sep 2013 23:50:56 -0700 (PDT)
Message-ID: <D0A2FE73E8354EDCBEE56EC79268CA4E@maumau>
From: "MauMau" <maumau307@gmail.com>
To: <robertmhaas@gmail.com>,
	"Tatsuo Ishii" <ishii@postgresql.org>
Cc: <ishii@postgresql.org>, <tgl@sss.pgh.pa.us>,
 <maksymb@fast.au.fujitsu.com>,
 <hlinnakangas@vmware.com>, <pgsql-hackers@postgresql.org>
References: 
 <CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com><20130920.085853.1628917054830864151.t-ishii@sraoss.co.jp><CA+TgmoZEy=pt2B5D+nuPAib7KvhNoBgRGYRWnkS4pyrqfcdYHQ@mail.gmail.com>
 <20130922.072952.1977066018971837040.t-ishii@sraoss.co.jp>
In-Reply-To: <20130922.072952.1977066018971837040.t-ishii@sraoss.co.jp>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Mon, 23 Sep 2013 15:53:02 +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>
> I don't think the bind placeholder is the case. That is processed by
> exec_bind_message() in postgres.c. It has enough info about the type
> of the placeholder, and I think we can easily deal with NCHAR. Same
> thing can be said to COPY case.

Yes, I've learned it.  Agreed.  If we allow an encoding for NCHAR different 
from the database encoding, we can convert text from the client encoding to 
the NCHAR encoding in nchar_in() for example.  We can retrieve the NCHAR 
encoding from pg_database and store it in a global variable at session 
start.


> Problem is an ordinary query (simple protocol "Q" message) as you
> pointed out. Encoding conversion happens at a very early stage (note
> that fast-path case has the same issue). If a query message contains,
> say, SHIFT-JIS and EUC-JP, then we are going into trouble because the
> encoding conversion routine (pg_client_to_server) regards that the
> message from client contains only one encoding. However my question
> is, does it really happen? Because there's any text editor which can
> create SHIFT-JIS and EUC-JP mixed text. So my guess is, when user want
> to use NCHAR as SHIFT-JIS text, the rest of query consist of either
> SHIFT-JIS or plain ASCII. If so, what the user need to do is, set the
> client encoding to SJIFT-JIS and everything should be fine.
>
> Maumau, is my guess correct?

Yes, I believe you are right.  Regardless of whether we support multiple 
encodings in one database or not, a single client encoding will be 
sufficient for one session.  When receiving the "Q" message, the whole SQL 
text is converted from the client encoding to the database encoding.  This 
part needs no modification.  During execution of the "Q" message, NCHAR 
values are converted from the database encoding to the NCHAR encoding.

Thank you very much, Tatsuo san.  Everybody, is there any other challenge we 
should consider to support NCHAR/NVARCHAR types as distinct 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