> 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 in UTF-8 encoding has a storage size of 3 bytes while it occupies spaces only twice of ASCII characters on a terminal. Same thing 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
