>> I think Tom's point is, there are tons of applications which define >> their own "int64_t" (at least in 2005). >> Also pg_config.h has: >> >> #define HAVE_STDINT_H 1 >> >> and this suggests that PostgreSQL adopts to platforms which does not >> have stdint.h. If so, we need to take care of such platforms anyway. >> > OK, it makes me clear. It might be helpful a source code comment > to remain why we used self defined datatype here.
Ok. > 2012/9/21 Tom Lane <t...@sss.pgh.pa.us>: >> Tatsuo Ishii <is...@postgresql.org> writes: >>> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr >>> is a pointer to 64-bit integer and actual data is placed somewhere >>> else. >> >> Yeah, I think we have to do it like that. Changing the size of >> PQArgBlock would be a libpq ABI break, which IMO is sufficiently painful >> to kill this whole proposal. Much better a little localized ugliness >> in fe-lobj.c. >> > Hmm, I see. Please deliver the 64bit integer argument as reference, > and don't forget endian translations here. I thought pgPutInt64() takes care of endianness. No? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers