Re: 64-bit API for large object

2012/9/21 Tatsuo Ishii <ishii(at)postgresql(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Tatsuo Ishii <ishii(at)postgresql(dot)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 <kaigai(at)kaigai(dot)gr(dot)jp>