2012/9/21 Tatsuo Ishii <is...@postgresql.org>: >>> 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? > It works inside of the PGfn(), when isint = 1 towards pointer data type. In my sense, it is a bit problem specific solution.
So, I'd like to see other person's opinion here. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers