Re: Multibyte char encoding atttypmod weirdness

Sorry but I made a mistake in describing the problem.

PQfmod(...) returns 20 + 4, but strlen(PQgetvalue(...)) returns
something varying, more than 24.

Since you said atttypmod is char len + 4, "The actual physical length in
bytes of a column entry might be more", it's dependant to the current
locale settings and multibyte/wide char related functions should be used
to calculate the byte length. Is there a simple and direct way to know
this byte lenght through libpq API? I will try to figure it out.

Thank you very much for you informative and helpful reply.

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Huaxin WANG" <wanghx(at)netspeed-tech(dot)com>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Sent: Monday, February 24, 2003 11:07 PM
Subject: Re: [BUGS] Multibyte char encoding atttypmod weirdness

> "Huaxin WANG" <wanghx(at)netspeed-tech(dot)com> writes:
> > When locale is set to multibyte char encoding languages,
> > such as ja_JP.eucjp, and char encoding set to EUC_JP, for the
char(20)
> > columns (attributes), the libpq ((PGresult
*)res)->attDescs[0].atttypmod
> > returned by PQfmod(res, 0) is not correct. It's neither 20, nor
20+4 as
> > reported in the hackers' mail list [1], but something varying (which
I
> > failed
> > to figure out). In my specific case, it's 25.
>
> I don't think so. A column declared as char(N) *will* have an
atttypmod
> of N+4. The actual physical length in bytes of a column entry might
> be more, though, since we measure N in terms of characters not bytes.
>
> regards, tom lane
>