On Thu, Nov 24, 2005 at 09:23:55PM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > And what I'm saying is that you can only do that if all single byte
> > encodings are ASCII compatable and I'm not prepared to say that...
>
> psql already assumes that; see the flex processor.
Hmm, Ok, I didn't realise that.
> > So in the switch statement I listed the encodings I know to be ASCII
> > compatable and at some point someone who actually knows the other
> > encodings will explain what needs to be done.
>
> Even if this were an appropriate solution, the formatting code is not
> the place to put such knowledge...
It adds two functions to mbprint.c:
pg_wcssize - To calculate the screen size required by the string (rows&cols)
pg_wcsformat - To actually format the text in the given lines
I agree that these should actually be operating system functions but we
can't rely on them. psql already has functions there for validating
UTF-8 and converting UTF-8 to UCS so it's in the right place in that
sense.
If you think it's better moved to libpq I can do that. There is a fair
bit of encoding code in there already but the information you need here
is specifically: is this char a control character and in particular, is
it a newline.
Most standard encoding implementations return a screen width of zero
for control characters, but we dont do that. I am hopeful once we have
ICU support we can do away with the enumeration since we can simply
read the Unicode Character database and get consistant results
everywhere for all encodings. But until that is done I think this is
the best we can do.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
