From: | Volkan YAZICI <volkan(dot)yazici(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How TODO prevent PQfnumber() from lowercasing? |
Date: | 2005-10-14 08:55:56 |
Message-ID: | 7104a7370510140155y60ad99c3h384b4f626683f060@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 10/13/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2005-10-14 09:14:34 | Re: Link problems with HEAD |
Previous Message | Tatsuo Ishii | 2005-10-14 08:47:32 | Re: Allowed timezone values |