Thread: How TODO prevent PQfnumber() from lowercasing?
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? Regards.
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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?