Hi,
On 10/13/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Really, PQfnumber shouldn't do any case folding at all; that's not in
> its charter if you ask me. The problem is how to get there from here
> without too much compatibility pain. Maybe invent a new routine that
> does it right and then deprecate the existing one?
Related with the ILIKE case (which requires lowercasing too), I've
been trying to implement a patch for MatchTextIC() in
backend/utils/adt/like_match.c and stucked at the same point with
PQfnumber() lowercasing. (Which is another bogus implementation.)
As I try and understand, it's so hard to implement a case processing
routine for both multi-byte and normal ASCII chars. wchar_t and char
types make comparisions really messy. By looking at some MySQL source
code, I suggest a new solution for string handling: If PostgreSQL is
compiled with --enable-mb parameter, then use wchar_t instead of char
in every string operation. I'm aware of the required huge
implementation for this purpose, but IMHO things will be at the right
position. It's a MB char or ASCII, not both. That's all.
Any opinions?
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
