Re: proposal: UTF8 to_ascii function

From: Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: UTF8 to_ascii function
Date: 2008-08-11 13:23:29
Message-ID: 48A03D51.3050105@students.mimuw.edu.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-08-11 13:42:36 Re: proposal: UTF8 to_ascii function
Previous Message Andrew Dunstan 2008-08-11 13:17:28 Re: proposal: UTF8 to_ascii function