On Sun, Sep 29, 2019 at 3:38 AM Alvaro Herrera wrote:
>
> The UTF8 bits looks reasonable to me. I guess the other part of that
> question is whether we support any other multibyte encoding that
> supports combining characters. Maybe for cases other than UTF8 we can
> test for 0-width chars (usin
On 2019-Sep-22, Juan José Santamaría Flecha wrote:
> The attached patch addresses the comment about assuming UTF8.
The UTF8 bits looks reasonable to me. I guess the other part of that
question is whether we support any other multibyte encoding that
supports combining characters. Maybe for cases
On Sat, Sep 21, 2019 at 2:42 AM Alvaro Herrera wrote:
>
> On 2019-Sep-20, Tom Lane wrote:
>
> > If we're going to start worrying about non-normalized characters,
> > I suspect there are far more places than this one that we'd have
> > to consider buggy :-(.
>
> I would think that we have to start
On 2019-Sep-20, Tom Lane wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
> writes:
> > I have come around a strange situation when using a unicode string
> > that has non normalized characters. The attached script 'initcap.sql'
> > can reproduce the problem.
For illustration purposes
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> I have come around a strange situation when using a unicode string
> that has non normalized characters. The attached script 'initcap.sql'
> can reproduce the problem.
> The attached patch can fix the issue.
If we're going to start worr
Hello,
I have come around a strange situation when using a unicode string
that has non normalized characters. The attached script 'initcap.sql'
can reproduce the problem.
The attached patch can fix the issue.
Regards,
Juan José Santamaría Flecha
initcap.sql
Description: application/sql
diff -
