Version: PostgreSQL 7.2.1 (7.3 not tested) Summary:
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. Is it a bug, or a feature that needs special care which is not documented in the postgresql documents? Is this extra byte overhead reflected by VARHDRSZ? But a simple fgrep -r VARHDRSZ in the header files showed: internal/c.h:#define VARHDRSZ ((int32) sizeof(int32)) internal/c.h: * always VARSIZE(ptr) - VARHDRSZ. server/access/tuptoaster.h: VARHDRSZ)) server/utils/varbit.h:/* Header overhead *in addition to* VARHDRSZ */ server/utils/varbit.h:#define VARBITBYTES(PTR) (VARSIZE(PTR) - VARHDRSZ - VARBITHDRSZ) server/utils/varbit.h: VARHDRSZ + VARBITHDRSZ) server/c.h:#define VARHDRSZ ((int32) sizeof(int32)) server/c.h: * always VARSIZE(ptr) - VARHDRSZ. which means VARHDRSZ should be sizeof(int32), which is always a constant 4 bytes. Is the VARBITHDRSZ relevant to this problem? But VARBITHDRSZ is not defined in any header files "make install-all-headers" installed. BTW, if it's not a bug, this kind of implementation inconsistent with common sense is ugly and a potential of buggy code. [1] http://archives.postgresql.org/pgsql-hackers/1998-03/msg00430.php ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
