> > For me, your patche seems to be a retrogression. In my understanding,
> > the reason why PostgreSQL uses "char *" in many places is just it was
> > designed in the old days when ASCII was the only charset in the world.
> Are you proposing that we change all the "char *" to "unsigned char *"?
No, I suggest we change all "char *" to "unsigned char *" only where
it points a string which could hold non ASCII character strings. I
thought we learned the danger of 1) comparing chars with signed bit
on, 2) passing chars with sign bit on to functions which expect int
> I looked at that briefly but it seems like a huge loss, both in
> notational ugliness and in the amount of code that would have to be
If you are just care the amount of effort, why don't you leave as it
is and use pre v4 gcc? :-)
> Also, it would force us to add a bunch of explicit casts to
> avoid warnings with standard library functions like strlen().
Counter examples could be easily found in isalpha(), toupper() etc.
> To me the
> bottom line is that 99% of the code only needs to know that a character
> string is a character string. As this patch demonstrates, there is only
> a tiny fraction that needs to have the "unsigned" declaration. I don't
> think we should allow that fraction to dictate a notational burden for
> all the rest.
To support multiple charsets/collataions, I think we need to change
the way to represent character strings from the unstructured "char *"
to more intelligent structure (I know it's hard to implement that
without significant performance loss, but I know we should do it in
So "unsigned char*" is not enough for the goal anyway, I'm not against
SRA OSS, Inc. Japan
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly