From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Case Conversion Functions |
Date: | 2005-12-27 00:01:07 |
Message-ID: | 15691.1135641667@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2005-12-27 12:17:42 | Handling of build-time enabled GUC settings |
Previous Message | Andrew Dunstan | 2005-12-26 22:49:29 | Re: [PATCHES] default resource limits |