Re: [PATCH] Formatting patch for psql

On Fri, Nov 25, 2005 at 09:58:21AM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > ... 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.
>
> The appropriate test for that is just "ch == '\n'", in all the encodings
> we support (although you do have to be careful that ch isn't a non-first
> byte of a multibyte character). If that's all you need then inventing
> a bunch of additional infrastructure is really inappropriate.

Well, not quite. What about \r (on windows in particular) or \t or
Unicode 0xFEFF (zero width non-breaking space)? For Latin-1 and other
locales based upon ASCII I use (ch < 32) for control characters, not
entirely correct but close.

For UTF-8 I use the function ucs_wcwidth() which already existed in
psql. It already knows what the control characters are, though I have
no idea how up-to-date its table is.

The reason I need to know whether a character is a control character or
not is so it can be printed as a \uNNNN string. Otherwise any of those
characters will destroy the alignment on the screen bringing us right
back to what psql does now: splatter across the screen when there are
control characters in the output.

I didn't add any new information to psql, I just took advantage of what
was already there. The comment about using PQdsplen() is good, but the
routines in libpq are totally inadequate, the utf8 function has a huge
FIXME next to it.

Would people prefer a patch that brought the libpq routines up to
scratch and have mbprint use that?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)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.