Message-ID: <5240B212.8040307@gmx.net>
Date: Mon, 23 Sep 2013 17:26:42 -0400
From: Peter Eisentraut <peter_e@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: MauMau <maumau307@gmail.com>
CC: robertmhaas@gmail.com, Tatsuo Ishii <ishii@postgresql.org>,
 tgl@sss.pgh.pa.us, maksymb@fast.au.fujitsu.com, hlinnakangas@vmware.com,
 pgsql-hackers@postgresql.org
Subject: Re: UTF8 national character data type support WIP patch
 and list of open issues.
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>
 <D0A2FE73E8354EDCBEE56EC79268CA4E@maumau>
In-Reply-To: <D0A2FE73E8354EDCBEE56EC79268CA4E@maumau>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 9/23/13 2:53 AM, MauMau wrote:
> 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.

That assumes that the conversion client encoding -> server encoding ->
NCHAR encoding is not lossy.  I thought one main point of this exercise
was the avoid these conversions and be able to go straight from client
encoding into NCHAR.


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