> Please find attached my first attempt at providing a localisation
> information on the client side for syntax errors in "psql". Basically, one
> function is added which takes care of the burden. I put a lot of
> comments in the function to try make it clear what is going on.
>
> It validates for me against current cvs head.
>
> I've also added new regression tests in "errors.sql".
>
> Although I have taken great and painful care to deal with multi-byte
> encodings, I'm not sure how I can validate that, as I don't have some
> japanese terminal to play with.
As far as I understand your code, it will be broken on many multi byte
encodings.
1) a character is not always represented on a terminal propotional to the storage size. For example a kanji character
inUTF-8 encoding has a storage size of 3 bytes while it occupies spaces only twice of ASCII characters on a terminal.
Samething can be said to LATIN 2,3 etc. in UTF-8 perhaps.
2) It assume all encodings are "ASCII compatible". Apparently some client-side-only encodings do not satisfy this
request.Examples include SJIS, Big5.
I think 2) would be solved by carefull codings.
However 1) is hard to solve. We need kind of a mapping table between
"storage size" and "terminal size" for each encoding. Note that this
is not new problem, and sophiscated editors such as Emacs (mule) has
already concur that.
--
Tatsuo Ishii
