Re: texteq/byteaeq: avoid detoast [REVIEW]
От | Pavel Stehule |
---|---|
Тема | Re: texteq/byteaeq: avoid detoast [REVIEW] |
Дата | |
Msg-id | AANLkTimTQFvamwjBeb8RcmqghQf6CtJauROVo7Mm-H5T@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: texteq/byteaeq: avoid detoast [REVIEW] (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Список | 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 по дате отправления: