From: "Peter Eisentraut" <pete...@gmx.net>
That assumes that the conversion client encoding -> server encoding -> NCHAR encoding is not lossy.
Yes, so Tatsuo san suggested to restrict server encoding <-> NCHAR encoding combination to those with lossless conversion.
I thought one main point of this exercise was the avoid these conversions and be able to go straight from client encoding into NCHAR.
It's slightly different. Please see the following excerpt: http://www.postgresql.org/message-id/B1A7485194DE4FDAB8FA781AFB570079@maumau "4. I guess some users really want to continue to use ShiftJIS or EUC_JP for database encoding, and use NCHAR for a limited set of columns to store international text in Unicode: - to avoid code conversion between the server and the client for performance - because ShiftJIS and EUC_JP require less amount of storage (2 bytes for most Kanji) than UTF-8 (3 bytes) This use case is described in chapter 6 of "Oracle Database Globalization Support Guide"." 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