Re: proposal: UTF8 to_ascii function

Поиск
Список
Период
Сортировка
От Jan Urbański
Тема Re: proposal: UTF8 to_ascii function
Дата
Msg-id 48A03D51.3050105@students.mimuw.edu.pl
обсуждение исходный текст
Ответ на Re: proposal: UTF8 to_ascii function  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: proposal: UTF8 to_ascii function  (Andrew Dunstan <andrew@dunslane.net>)
Re: proposal: UTF8 to_ascii function  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Andrew Dunstan wrote:
>
>
> Pavel Stehule wrote:
>>
>>
>> One note - convert_to is correct. But we have to use to_ascii without
>> decode functions. It has same behave - convert from bytea to text.
>> Text in "incorrect" encoding is dafacto bytea. So correct to_ascii
>> function prototypes are:
>>
>> to_ascii(text)
>> to_ascii(bytea, integer);
>> to_ascii(bytea, name);
>>
>>
>>>
>
> What you have not said is how you propose to convert UTF8 to ASCII.
>
> Currently to_ascii() converts a small number of single byte charsets to
> ASCII by folding the chars with high bits set, so what we get is a pure
> ASCII result which is safe in any server encoding, as they are all ASCII
> supersets.
>
> But what conversion rule will you use for the gazillions of Unicode
> characters?
>
> I honestly do not understand the use case for this at all.

I do. Often clients want their searches to be
accented-or-language-specific letters insensitive. So searching for
'łódź' returns 'lodz'. So the use case is there (in fact, the lack of
such facility made me consider not upgrading particular client to 8.3...).
Or maybe there's a better way to do it?

Cheers,
Jan

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: proposal: UTF8 to_ascii function
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: proposal: UTF8 to_ascii function