Dear Tatsuo,
Thanks for your reply, as I noticed from the source code that your name
often appears when dealing with multi-byte issues;-)
On Fri, 12 Mar 2004, Tatsuo Ishii wrote:
As far as I understand your code, it will be broken on many multi byte
encodings.
1) a character is not always
Fabien COELHO wrote:
There is also a localisation issue here, as the translation of both
lines must match so that the alignment is kept. I thought that if it
is the very same word, the translation should be the same.
You can just indent with as many spaces. This is done in other places
Dear Tatsuo,
Thanks for your reply, as I noticed from the source code that your name
often appears when dealing with multi-byte issues;-)
On Fri, 12 Mar 2004, Tatsuo Ishii wrote:
As far as I understand your code, it will be broken on many multi byte
encodings.
1) a character is not
PQmblen returns the storage size, which is not necessarily same as the
character width reprensented in a terminal. For example for a kanji
character in UTF-8 PQmblen returns 3, but it ocuppies 2 x ASCII
character space, not x 3. Isn't that a problem for you?
2) It assume all encodings are
Dear Tatsuo,
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
PQmblen returns the storage size, which is not necessarily same as the
character width reprensented in a terminal. For example for a kanji
character in UTF-8 PQmblen returns 3, but it ocuppies 2 x ASCII
character space, not x 3. Isn't that a problem for you?
If I read you correctly, you
Fabien COELHO [EMAIL PROTECTED] writes:
As a compromise, I can suggest the following:
LINE 4: WHERE id=123 AND name LIKE 'calvin' GROP BY name...
^
That works for me. I don't mind it saying LINE 1: in the one-line case.
It's not going to add more
Dear Tatsuo,
One thing I have to note is that some Asian characters such as Japanese,
Chinese require twice the space on a terminal for each character
comparing with plain ASCII characters. This is hard to explain to those
who are not familiar with kanji...
I learnt a little bit of chinese
Could you take a look at included screen shot?
I haven't found it. However I've made a little bit of trying with my
Oops. I have included this time.
Maybe you could point me some source of information about display lengths
of characters depending on the encoding?
I could write
On Sat, 13 Mar 2004, Tatsuo Ishii wrote:
Oops. I have included this time.
How ! a japanese vi !
I could write PQmbtermlen function for every encoding supported by
PostgreSQL
That would be great ! ;-)
Ok, I will work on this.
Thanks.
--
Fabien Coelho - [EMAIL PROTECTED]
Dear patchers,
Sorry, wrong list:-(
--
Fabien.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Fabien COELHO [EMAIL PROTECTED] writes:
Please find attached my first attempt at providing a localisation
information on the client side for syntax errors in psql.
Localisation tends to mean something quite different around here.
I'd suggest renaming the function to something like
Fabien COELHO [EMAIL PROTECTED] writes:
The on line N bit seems just noise to me.
It depends.
I can see that it would be useful in a very large query. Perhaps
include it only when the query has more than N lines, for some N
like three to five or so?
Another possibility is to keep the cursor
Dear Tom,
The on line N bit seems just noise to me.
It depends.
I can see that it would be useful in a very large query. Perhaps
include it only when the query has more than N lines, for some N
like three to five or so?
Yes, I can do that.
Another possibility is to keep the cursor as
Dear Tom,
Please find attached my first attempt at providing a localisation
information on the client side for syntax errors in psql.
Localisation tends to mean something quite different around here. I'd
suggest renaming the function to something like ReportSyntaxErrorPosition.
Ok.
Fabien COELHO [EMAIL PROTECTED] writes:
Another possibility is to keep the cursor as just ^, and bury the
line info in the query extract. For instance:
Well, I want to preserve space for the query extract, that's where the
context information is! If I put more information there, I'll have to
Fabien COELHO wrote:
There is also a localisation issue here, as the translation of both
lines must match so that the alignment is kept. I thought that if it
is the very same word, the translation should be the same.
You can just indent with as many spaces. This is done in other places
as
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
Dear Tom,
Well, I want to preserve space for the query extract, that's where the
context information is! If I put more information there, I'll have to
reduce the extract length.
But in the form you are using, you have to reserve that space anyway.
Consider an error marker at the end of
19 matches
Mail list logo
