Alexander Korotkov writes:
> On Sun, Apr 7, 2013 at 10:00 PM, Tom Lane wrote:
>> Hm, actually couldn't we just simplify to "if (bytelen != charlen)"?
> I think yes, we can :)
OK. I pushed this as a separate commit so as to highlight the potential
incompatibility in the commit log. I am not su
On Sun, Apr 7, 2013 at 10:00 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > It's also likely we can change
> >if (pg_database_encoding_max_length() > 1)
> > into something like
> >if (pg_database_encoding_max_length() > 1 && bytelen != charlen)
>
> Hm, actually couldn't we just sim
Alexander Korotkov writes:
> It's also likely we can change
>if (pg_database_encoding_max_length() > 1)
> into something like
>if (pg_database_encoding_max_length() > 1 && bytelen != charlen)
Hm, actually couldn't we just simplify to "if (bytelen != charlen)"?
reg
On Sun, Apr 7, 2013 at 7:43 PM, Tom Lane wrote:
> While reviewing the latest incarnation of the regex indexing patch,
> I noticed that make_trigrams() in contrib/pg_trgm/trgm_op.c is coded
> so that if USE_WIDE_UPPER_LOWER is not set, it ignores multibyte
> character boundaries and just makes tri
While reviewing the latest incarnation of the regex indexing patch,
I noticed that make_trigrams() in contrib/pg_trgm/trgm_op.c is coded
so that if USE_WIDE_UPPER_LOWER is not set, it ignores multibyte
character boundaries and just makes trigrams from 3-byte substrings.
This seems slightly insane,
