Re: client side syntax error localisation for psql (v1) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: client side syntax error localisation for psql (v1)
Date
Msg-id Pine.GSO.4.58.0403121451060.19395@elvis
Whole thread Raw
In response to Re: client side syntax error localisation for psql (v1)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: client side syntax error localisation for psql (v1)
List pgsql-hackers
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 a few years ago, but I never saw the
computer version.

> 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
emacs 21 mule demonstration, and indeed there is two different character
widths...

> As you can see there are four ASCII characters in the first line. On the
> second line there are *two* kanji characters and they occupy same space
> as above four ASCII characters. Moreover the strage size for the first
> line is 4, but the strage size for the second line may vary depending on
> the encoding. If the encoding is EUC_JP or SJIS, it takes 4 bytes,
> however it takes 6 bytes if the encoding is UTF-8. Got it?

Yep.

> > Maybe you could point me some source of information about display lengths
> > of characters depending on the encoding?
>
> I could write "PQmbtermlen" function for every encoding supported by
> PostgreSQL

That would be great ! ;-)

> except UTF-8. Such kind of info for UTF-8 might be quite
> complex. I believe there are some mapping tables or functions to get
> such kind of info somewhere on the Internet, but I don't remember.

That would be even greater;-)

I guess a "return 1" version would be a false quick fix that could
be improved later on...

-- 
Fabien COELHO.


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: The Name Game: postgresql.net vs. pgfoundry.org
Next
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: The Name Game: postgresql.net vs. pgfoundry.org