Re: UTF8 national character data type support WIP patch and list of open issues. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: UTF8 national character data type support WIP patch and list of open issues.
Date
Msg-id 5240B212.8040307@gmx.net
Whole thread Raw
In response to Re: UTF8 national character data type support WIP patch and list of open issues.  ("MauMau" <maumau307@gmail.com>)
Responses Re: UTF8 national character data type support WIP patch and list of open issues.
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: SSL renegotiation
Next
From: Stephen Frost
Date:
Subject: Re: record identical operator