Hi,

I have been working a bit at a patch for that problem in psql. The
patch is far from being ready for inclusion or whatever, it's just for
comments...

By the way, someone can tell me how to generate nice patches showing
the difference between one's version and the cvs code that has been
downloaded ? I'm new to this (I've only used cvs for personal projects
so far, and I don't need to send patches to myself ;) ).

The good things in this patch :

- it works for me :)

- I've used Markus Kuhn's implementation of wcwidth.c : it is locale
  independant, and is in the public domain. :) [if we keep it, I'll
  have to tell him, though !]

- No dependency on the local libc's UTF-8-awareness ;) [I've seen that
  psql has no such dependancy, at least in print.c, so I haven't added
  any]. Actually, the change is completely self-contained.

- I've made my own utf-8 -> ucs converter, since I haven't found any
  without a copyright notice yesterday. It checks invalid and
  non-optimal UTF-8 sequences, as requested per Unicode 3.0.1 (or 3.1,
  I don't remember).

- it works for japanese (and I believe other "full-width" characters).

- if MULTIBYTE is not defined, the code doesn't change from the
  commited version.

The not so good things :

- I've made my own utf-8 -> ucs converter... It seems to work fine,
  but it's not tested well enough, it may not be so robust.

- The printf( "%*s", width, utfstr) doesn't work as expected, so I had
  to fix by doing printf( "%*s%s", width - utfstrwidth, "", utfstr);

- everything in #ifdef MULTIBYTE/#endif . Since they're is no
  dependancy on anything else (including the rest of the multibyte
  implementation - which I haven't had the time to look at in detail),
  it doesn't depend on it.

- I get this (for each call to pg_mb_utfs_width) and I don't know why :

  print.c:265: warning: passing arg 1 of `pg_mb_utfs_width' discards
  qualifiers from pointer target type

- If pg_mb_utfs_width finds an invalid UTF-8 string, it truncates it.
  I suppose that's what we want to do, but that's probably not the
  best place to do it.

The bad things :

- If MULTIBYTE is defined, the strings must be in UTF-8, it doesn't
  check any encoding.

- it is not integrated at all with the rest of the MB code.

- it doesn't respect the indentation policy ;)


To do :

- integrate better with the rest of the MB (client-side encoding), and
  with the rest of the code of print.c .

- verify utf8-to-ucs robustness seriously.

- make a visually nicer code :)

- find better function names.

And possibly :

- consolidate the code, in order to remove the need for the #ifdef's
  in many places.

- make it working with some others multiwidth-encoding (but then, I
  don't know anything about these encodings myself !).

- check also utf-8 stream at input time, so that no invalid utf-8 is
  sent to the backend (at least from psql - the backend will need also
  a strict checking for UTF-8).

- add nice UTF-8 borders as an option :)

- add a command-line parameter to consider Unicode Ambiguous
  characters (characters which can be narrow or wide, depending on the
  terminal) wide characters, as it seems to be the case for CJK
  terminals (as per TR#11).

- What else ?


BTW, here is the table I had in the first mail. I would have shown the
one with all the weird Unicode characters, but my mutt is configured
with iso-8859-15, and I doubt many of you have utf-8 as a default yet
:)

+------+-------+--------+
| lang | text  |  text  |
+------+-------+--------+
| isl  | ï¿œlï¿œta | ï¿œleit  |
| isl  | ï¿œlï¿œta | ï¿œlitum |
| isl  | ï¿œlï¿œta | ï¿œlitiï¿œ |
| isl  | maï¿œur | mann   |
| isl  | maï¿œur | mï¿œnnum |
| isl  | maï¿œur | manna  |
| isl  | ï¿œska  | -aï¿œi   |
+------+-------+--------+


The files in attachment :
- a diff for pgsql/src/bin/psql/print.c
- a diff for pgsql/src/bin/psql/Makefile
- two new files :
  pgsql/src/bin/psql/pg_mb_utf8.c
  pgsql/src/bin/psql/pg_mb_utf8.h

Have fun !

Patrice

-- 
Patrice Hï¿œDï¿œ ------------------------------- patrice ï¿œ islande org -----
  --  Isn't it weird  how scientists  can imagine  all the matter of the
universe exploding out of a dot smaller than the head of a pin, but they
can't come up with a more evocative name for it than "The Big Bang" ?
  -- What would _you_ call the creation of the universe ?
  -- "The HORRENDOUS SPACE KABLOOIE !"               - Calvin and Hobbes
------------------------------------------ http://www.islande.org/ -----
Wed, 26 Sep 2001 20:23:33 +0200
Patrice =?iso-8859-15?Q?H=E9d=E9?= <phede-ml@islande.org>
Combining chars in psql (pre-patch)

Patrice, do you have an updated patch you want applied to 7.3?

---------------------------------------------------------------------------

Patrice H�d� wrote:
> Hi,
> 
> I have been working a bit at a patch for that problem in psql. The
> patch is far from being ready for inclusion or whatever, it's just for
> comments...
> 
> By the way, someone can tell me how to generate nice patches showing
> the difference between one's version and the cvs code that has been
> downloaded ? I'm new to this (I've only used cvs for personal projects
> so far, and I don't need to send patches to myself ;) ).
> 
> The good things in this patch :
> 
> - it works for me :)
> 
> - I've used Markus Kuhn's implementation of wcwidth.c : it is locale
>   independant, and is in the public domain. :) [if we keep it, I'll
>   have to tell him, though !]
> 
> - No dependency on the local libc's UTF-8-awareness ;) [I've seen that
>   psql has no such dependancy, at least in print.c, so I haven't added
>   any]. Actually, the change is completely self-contained.
> 
> - I've made my own utf-8 -> ucs converter, since I haven't found any
>   without a copyright notice yesterday. It checks invalid and
>   non-optimal UTF-8 sequences, as requested per Unicode 3.0.1 (or 3.1,
>   I don't remember).
> 
> - it works for japanese (and I believe other "full-width" characters).
> 
> - if MULTIBYTE is not defined, the code doesn't change from the
>   commited version.
> 
> The not so good things :
> 
> - I've made my own utf-8 -> ucs converter... It seems to work fine,
>   but it's not tested well enough, it may not be so robust.
> 
> - The printf( "%*s", width, utfstr) doesn't work as expected, so I had
>   to fix by doing printf( "%*s%s", width - utfstrwidth, "", utfstr);
> 
> - everything in #ifdef MULTIBYTE/#endif . Since they're is no
>   dependancy on anything else (including the rest of the multibyte
>   implementation - which I haven't had the time to look at in detail),
>   it doesn't depend on it.
> 
> - I get this (for each call to pg_mb_utfs_width) and I don't know why :
> 
>   print.c:265: warning: passing arg 1 of `pg_mb_utfs_width' discards
>   qualifiers from pointer target type
> 
> - If pg_mb_utfs_width finds an invalid UTF-8 string, it truncates it.
>   I suppose that's what we want to do, but that's probably not the
>   best place to do it.
> 
> The bad things :
> 
> - If MULTIBYTE is defined, the strings must be in UTF-8, it doesn't
>   check any encoding.
> 
> - it is not integrated at all with the rest of the MB code.
> 
> - it doesn't respect the indentation policy ;)
> 
> 
> To do :
> 
> - integrate better with the rest of the MB (client-side encoding), and
>   with the rest of the code of print.c .
> 
> - verify utf8-to-ucs robustness seriously.
> 
> - make a visually nicer code :)
> 
> - find better function names.
> 
> And possibly :
> 
> - consolidate the code, in order to remove the need for the #ifdef's
>   in many places.
> 
> - make it working with some others multiwidth-encoding (but then, I
>   don't know anything about these encodings myself !).
> 
> - check also utf-8 stream at input time, so that no invalid utf-8 is
>   sent to the backend (at least from psql - the backend will need also
>   a strict checking for UTF-8).
> 
> - add nice UTF-8 borders as an option :)
> 
> - add a command-line parameter to consider Unicode Ambiguous
>   characters (characters which can be narrow or wide, depending on the
>   terminal) wide characters, as it seems to be the case for CJK
>   terminals (as per TR#11).
> 
> - What else ?
> 
> 
> BTW, here is the table I had in the first mail. I would have shown the
> one with all the weird Unicode characters, but my mutt is configured
> with iso-8859-15, and I doubt many of you have utf-8 as a default yet
> :)
> 
> +------+-------+--------+
> | lang | text  |  text  |
> +------+-------+--------+
> | isl  | ?l?ta | ?leit  |
> | isl  | ?l?ta | ?litum |
> | isl  | ?l?ta | ?liti? |
> | isl  | ma?ur | mann   |
> | isl  | ma?ur | m?nnum |
> | isl  | ma?ur | manna  |
> | isl  | ?ska  | -a?i   |
> +------+-------+--------+
> 
> 
> The files in attachment :
> - a diff for pgsql/src/bin/psql/print.c
> - a diff for pgsql/src/bin/psql/Makefile
> - two new files :
>   pgsql/src/bin/psql/pg_mb_utf8.c
>   pgsql/src/bin/psql/pg_mb_utf8.h
> 
> Have fun !
> 
> Patrice
> 
> -- 
> Patrice H?D? ------------------------------- patrice ? islande org -----
>   --  Isn't it weird  how scientists  can imagine  all the matter of the
> universe exploding out of a dot smaller than the head of a pin, but they
> can't come up with a more evocative name for it than "The Big Bang" ?
>   -- What would _you_ call the creation of the universe ?
>   -- "The HORRENDOUS SPACE KABLOOIE !"               - Calvin and Hobbes
> ------------------------------------------ http://www.islande.org/ -----

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 22 Feb 2002 13:07:49 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Combining chars in psql (pre-patch)

"cvs diff -c" shows the differences from your source and cvs.

I am a little confused.  What functionality does this add?

---------------------------------------------------------------------------

Patrice H�d� wrote:
> Hi,
> 
> I have been working a bit at a patch for that problem in psql. The
> patch is far from being ready for inclusion or whatever, it's just for
> comments...
> 
> By the way, someone can tell me how to generate nice patches showing
> the difference between one's version and the cvs code that has been
> downloaded ? I'm new to this (I've only used cvs for personal projects
> so far, and I don't need to send patches to myself ;) ).
> 
> The good things in this patch :
> 
> - it works for me :)
> 
> - I've used Markus Kuhn's implementation of wcwidth.c : it is locale
>   independant, and is in the public domain. :) [if we keep it, I'll
>   have to tell him, though !]
> 
> - No dependency on the local libc's UTF-8-awareness ;) [I've seen that
>   psql has no such dependancy, at least in print.c, so I haven't added
>   any]. Actually, the change is completely self-contained.
> 
> - I've made my own utf-8 -> ucs converter, since I haven't found any
>   without a copyright notice yesterday. It checks invalid and
>   non-optimal UTF-8 sequences, as requested per Unicode 3.0.1 (or 3.1,
>   I don't remember).
> 
> - it works for japanese (and I believe other "full-width" characters).
> 
> - if MULTIBYTE is not defined, the code doesn't change from the
>   commited version.
> 
> The not so good things :
> 
> - I've made my own utf-8 -> ucs converter... It seems to work fine,
>   but it's not tested well enough, it may not be so robust.
> 
> - The printf( "%*s", width, utfstr) doesn't work as expected, so I had
>   to fix by doing printf( "%*s%s", width - utfstrwidth, "", utfstr);
> 
> - everything in #ifdef MULTIBYTE/#endif . Since they're is no
>   dependancy on anything else (including the rest of the multibyte
>   implementation - which I haven't had the time to look at in detail),
>   it doesn't depend on it.
> 
> - I get this (for each call to pg_mb_utfs_width) and I don't know why :
> 
>   print.c:265: warning: passing arg 1 of `pg_mb_utfs_width' discards
>   qualifiers from pointer target type
> 
> - If pg_mb_utfs_width finds an invalid UTF-8 string, it truncates it.
>   I suppose that's what we want to do, but that's probably not the
>   best place to do it.
> 
> The bad things :
> 
> - If MULTIBYTE is defined, the strings must be in UTF-8, it doesn't
>   check any encoding.
> 
> - it is not integrated at all with the rest of the MB code.
> 
> - it doesn't respect the indentation policy ;)
> 
> 
> To do :
> 
> - integrate better with the rest of the MB (client-side encoding), and
>   with the rest of the code of print.c .
> 
> - verify utf8-to-ucs robustness seriously.
> 
> - make a visually nicer code :)
> 
> - find better function names.
> 
> And possibly :
> 
> - consolidate the code, in order to remove the need for the #ifdef's
>   in many places.
> 
> - make it working with some others multiwidth-encoding (but then, I
>   don't know anything about these encodings myself !).
> 
> - check also utf-8 stream at input time, so that no invalid utf-8 is
>   sent to the backend (at least from psql - the backend will need also
>   a strict checking for UTF-8).
> 
> - add nice UTF-8 borders as an option :)
> 
> - add a command-line parameter to consider Unicode Ambiguous
>   characters (characters which can be narrow or wide, depending on the
>   terminal) wide characters, as it seems to be the case for CJK
>   terminals (as per TR#11).
> 
> - What else ?
> 
> 
> BTW, here is the table I had in the first mail. I would have shown the
> one with all the weird Unicode characters, but my mutt is configured
> with iso-8859-15, and I doubt many of you have utf-8 as a default yet
> :)
> 
> +------+-------+--------+
> | lang | text  |  text  |
> +------+-------+--------+
> | isl  | ?l?ta | ?leit  |
> | isl  | ?l?ta | ?litum |
> | isl  | ?l?ta | ?liti? |
> | isl  | ma?ur | mann   |
> | isl  | ma?ur | m?nnum |
> | isl  | ma?ur | manna  |
> | isl  | ?ska  | -a?i   |
> +------+-------+--------+
> 
> 
> The files in attachment :
> - a diff for pgsql/src/bin/psql/print.c
> - a diff for pgsql/src/bin/psql/Makefile
> - two new files :
>   pgsql/src/bin/psql/pg_mb_utf8.c
>   pgsql/src/bin/psql/pg_mb_utf8.h
> 
> Have fun !
> 
> Patrice
> 
> -- 
> Patrice H?D? ------------------------------- patrice ? islande org -----
>   --  Isn't it weird  how scientists  can imagine  all the matter of the
> universe exploding out of a dot smaller than the head of a pin, but they
> can't come up with a more evocative name for it than "The Big Bang" ?
>   -- What would _you_ call the creation of the universe ?
>   -- "The HORRENDOUS SPACE KABLOOIE !"               - Calvin and Hobbes
> ------------------------------------------ http://www.islande.org/ -----

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 6 Mar 2002 16:16:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Combining chars in psql (pre-patch)