Hi,
On Fri, Dec 21, 2018 at 5:08 PM, Tom Lane wrote:
> I don't think I buy that argument; it falls down as soon as you consider
> characters above U+. I worry that by supporting UTF16, we'd basically
> be encouraging users to write code that fails on such characters, which
> doesn't seem like
> * What's the benefit of supporting UTF16 in host variables?
I think that the first benefit of suggestion is providing a way to
treat UTF16 chars for application. Whether or not to support above
U+ (e.g. surrogate pair) may be a next discussion.
For that purpose, implementation for the sugge
"Nagaura, Ryohei" writes:
> Tsunakawa-san
>> * What's the benefit of supporting UTF16 in host variables?
> 1) As byte per character is constant in UTF16 encoding, it can process
> strings more efficiently than other encodings.
I don't think I buy that argument; it falls down as soon as you cons
Matsumura-san, Tsunakawa-san
Thank you for reply.
Tsunakawa-san
> * What's the benefit of supporting UTF16 in host variables?
There are two benefits.
1) As byte per character is constant in UTF16 encoding, it can process strings
more efficiently than other encodings.
2) This enables C programmer
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> There is a demand for ECPG to support UNICODE host variables.
> This topic has also appeared in thread [1].
> I would like to discuss whether to support in postgres.
>
> Do you have any opinion?
* What's the benefit of supporting UTF1
Nagaura-san
I understand that the previous discussion pointed that the feature had better
be implemented more simply or step-by-step and description about implementation
is needed more.
I also think it prevented the discussion to reach to the detail of feature.
What is your opinion about it?
Reg
