How TODO prevent PQfnumber() from lowercasing?

Volkan YAZICI wrote:

Hi,

Which way do you suggest to "Prevent libpq's PQfnumber() from
lowercasing the column name" (which is listed as a TODO item). If
column name has quotes around it we're just removing the quotes and
comparing with the related column name. Else, lowercasing the column
name and then comparing.

I couldn't get the idea behind this TODO. Can somebody explain it a
little bit more?

Good question. The TODO item is:

* Prevent libpq's PQfnumber() from lowercasing the column name?

The question mark means we are not sure how to deal with it. I think
your idea of using quotes to preserve case is a good one.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On 10/12/05, Bruce Momjian <pgman@candle.pha.pa.us> wrote:

The question mark means we are not sure how to deal with it. I think
your idea of using quotes to preserve case is a good one.

I think related TODO is added for that gotcha which was written in
PQfnumber() comments in fe-exec.c: «Downcasing in the frontend might
follow different locale rules than downcasing in the backend.»

Returned column names from the backend were lowercased by the server
in this or that way. Furthermore, PQfnumber() makes not-quoted strings
downcasing on the client side and then performs the compare by using
the results returned from the backend. To sum up, at the moment I
couldn't see any possible solution for this TODO. (I'll be appreciated
to hear your suggestions on the case.) An un-fixable situation?

Volkan YAZICI wrote:

On 10/12/05, Bruce Momjian <pgman@candle.pha.pa.us> wrote:

The question mark means we are not sure how to deal with it. I think
your idea of using quotes to preserve case is a good one.

I think related TODO is added for that gotcha which was written in
PQfnumber() comments in fe-exec.c: ?Downcasing in the frontend might
follow different locale rules than downcasing in the backend.?

Returned column names from the backend were lowercased by the server
in this or that way. Furthermore, PQfnumber() makes not-quoted strings
downcasing on the client side and then performs the compare by using
the results returned from the backend. To sum up, at the moment I
couldn't see any possible solution for this TODO. (I'll be appreciated
to hear your suggestions on the case.) An un-fixable situation?

Yes, I see now looking at the code. I have removed the TODO item. We
have had no complaints about its lowercasing, so I think we are OK.

The biggest issue was that some people were complaining that they didn't
expect the lowewcasing to happen at all.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Volkan YAZICI <volkan.yazici@gmail.com> writes:

Returned column names from the backend were lowercased by the server
in this or that way. Furthermore, PQfnumber() makes not-quoted strings
downcasing on the client side and then performs the compare by using
the results returned from the backend. To sum up, at the moment I
couldn't see any possible solution for this TODO. (I'll be appreciated
to hear your suggestions on the case.) An un-fixable situation?

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?

regards, tom lane

Tom Lane wrote:

Volkan YAZICI <volkan.yazici@gmail.com> writes:

Returned column names from the backend were lowercased by the server
in this or that way. Furthermore, PQfnumber() makes not-quoted strings
downcasing on the client side and then performs the compare by using
the results returned from the backend. To sum up, at the moment I
couldn't see any possible solution for this TODO. (I'll be appreciated
to hear your suggestions on the case.) An un-fixable situation?

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?

TODO updated:

* Prevent PQfnumber() from lowercasing unquoted the column name

PQfnumber() should never have been doing lowercasing, but historically
it has so we need a way to prevent it

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Hi,

On 10/13/05, Tom Lane <tgl@sss.pgh.pa.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?