Re: How TODO prevent PQfnumber() from lowercasing?

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?

In response to

Browse pgsql-hackers by date

  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