Re: [HACKERS] Case Conversion Functions

[Tom Lane]

Volkan YAZICI <[EMAIL PROTECTED]> writes:
> There're lots of places in the code which uses either pg_tolower()
> or just tolower() - without aware of MB characters; or some
> on-their-own implementations of pg_tolower(). (Actually, AFAIK,
> whole MB case conversion is broken in -rHEAD.)

The upper/lower functions themselves work AFAIK, but I agree that stuff
like ILIKE probably is broken for MB encodings.  regex character classes
need help too.

> Another example:
>   backend/parser/scansup.c
>   152 else if (ch >= 0x80 && isupper(ch))
>   153 ch = tolower(ch);

Fooling with that is fairly risky --- we've been burnt before by
locale-dependent case folding of SQL identifiers.  In particular
it'd be really bad if the folding could change on-the-fly at runtime.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[HACKERS] Case Conversion Functions

[Volkan YAZICI]

Hi,

There're lots of places in the code which uses either pg_tolower()
or just tolower() - without aware of MB characters; or some
on-their-own implementations of pg_tolower(). (Actually, AFAIK,
whole MB case conversion is broken in -rHEAD.)

For instance, consider backend/utils/adt/{like.c, like_match.c}
file. Some lines of iwchareq() are a duplication of pg_tolower().

Another example:
  backend/parser/scansup.c
  152 else if (ch >= 0x80 && isupper(ch))
  153 ch = tolower(ch);

Is this an intended behaviour or they're waiting for somebody to
clean them up.


Regards.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org