From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Subject: | Re: proposal: UTF8 to_ascii function |
Date: | 2008-08-12 06:58:39 |
Message-ID: | 48A1349F.9030804@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> On Monday 11 August 2008 16:23:29 Jan Urbański wrote:
>> 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...).
>
> These are valid ideas, but then please design a new function that addresses
> your use case in a well-defined way, and don't overload questionable old
> interfaces for new purposes.
>
> In the Unicode standard you can find well-defined methods to decompose
> characters into diacritic marks, and then you could strip them off. But this
> has nothing to do with ASCII or UTF8 or encodings. Cyrillic characters can
> have diacritic marks as well, for example.
OK, I was envisioning something like that:
http://search.cpan.org/~sburke/Text-Unidecode-0.04/lib/Text/Unidecode.pm
but now that I think of it, I can always just write a plperlu function
that uses that module. The only inconvenience is having to have plperlu
in the db, but I can live with that.
Postgres extensibility rocks and I rest my case.
Cheers,
Jan
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2008-08-12 07:26:31 | Re: Plugin system like Firefox |
Previous Message | Pavel Stehule | 2008-08-12 05:17:58 | Re: proposal: UTF8 to_ascii function |