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 PROTE
> > 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 co
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 chine
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 ad
> > 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 corre
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
> 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 encodi
> 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 cha
> 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
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 alway
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
> 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
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
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'l
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.
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 th
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 c
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 Report
> 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])
19 matches
Mail list logo
