From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | coelho(at)cri(dot)ensmp(dot)fr |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: client side syntax error localisation for psql (v1) |
Date: | 2004-03-12 01:21:23 |
Message-ID: | 20040312.102123.41631359.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-12 01:23:46 | Re: Log rotation |
Previous Message | Andrew Dunstan | 2004-03-12 01:13:35 | Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org |