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" <[EMAIL PROTECTED]> To: "Huaxin WANG" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 11:07 PM Subject: Re: [BUGS] Multibyte char encoding atttypmod weirdness > "Huaxin WANG" <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
