Alexey Mahotkin kirjutas K, 05.11.2003 kell 17:11:
> Aha, that's in src/backend/utils/adt/formatting.c, right?
>
> Yes, I see, it goes byte by byte and uses toupper(). I believe we
> could look at the locale, and if it is UTF-8, then use (or copy)
> e.g. g_utf8_strup/strdown, right?
>
>
> http://developer.gnome.org/doc/API/2.0/glib/glib-Unicode-Manipulation.html#g-utf8-strup
>
> I belive that patch could be written in a matter of hours.
>
>
> TL> There has been some discussion of using <wctype.h> where
> TL> available, but this has a number of issues, notably figuring
> TL> out the correct mapping from the server string encoding (eg
> TL> UTF-8) to unpacked wide characters. At minimum we'd need to
> TL> know which charset the locale setting is expecting, and there
> TL> doesn't seem to be a portable way to find that out.
>
> TL> IIRC, Peter thinks we must abandon use of libc's locale
> TL> functionality altogether and write our own locale layer before
> TL> we can really have all the locale-specific functionality we
> TL> want.
>
> I believe that native Unicode strings (together with human language
> handling) should be introduced as (almost) separate data type (which
> have nothing to do with locale), but that's bluesky maybe.
They should have nothing to do with _system_ locale, but you can
neither UPPER()/LOWER() nor ORDER BY unless you know the locale. It is
just that the locale should either be property of column or given in the
SQL statement.
I guess one could write UCHAR, UVARCHAR, UTEXT types based on ICU.
-------------
Hannu
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
