Re: texteq/byteaeq: avoid detoast [REVIEW] - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: texteq/byteaeq: avoid detoast [REVIEW]
Date
Msg-id AANLkTimTQFvamwjBeb8RcmqghQf6CtJauROVo7Mm-H5T@mail.gmail.com
Whole thread Raw
In response to Re: texteq/byteaeq: avoid detoast [REVIEW]  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List pgsql-hackers
2011/1/17 Itagaki Takahiro <itagaki.takahiro@gmail.com>:
> On Mon, Jan 17, 2011 at 16:13, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>> If we always generate same toasted byte sequences from the same raw
>>>> values, we don't need to detoast at all to compare the contents.
>>>> Is it possible or not?
>>>
>>> For bytea, it seems it would be possible.
>>>
>>> For text, I think locales may make that impossible. Aren't there
>>> locale rules where two different characters can "behave the same" when
>>> comparing them? I know in Swedish at least w and v behave the same
>>> when sorting (but not when comparing) in some variants of the locale.
>>>
>> Some string's comparation operations are binary now too. But it is
>> question what will be new with collate support.
>
> Right. We are using memcmp() in texteq and textne now. We consider
> collations only in <, <=, =>, > and compare support functions.
> So, I think there is no regression here as long as raw values and
> toasted byte sequences have one-to-one correspondence.
>

I am sure, so this isn't a problem in Czech locale, but I am not sure
about German or Turkish.

There was issue (if I remember well  with German "ss" char) ?

Pavel


> --
> Itagaki Takahiro
>


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: texteq/byteaeq: avoid detoast [REVIEW]
Next
From: Itagaki Takahiro
Date:
Subject: Re: texteq/byteaeq: avoid detoast [REVIEW]