> 2012/9/22 Tatsuo Ishii <ishii@postgresql.org>:
>> Tom, Kaigai,
>>
>>> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>>>> Tom, could you give us a suggestion which manner is better approach; whether
>>>> the PQfn should have responsibility for endian translation of 64bit-integer, or
>>>> callers (lo_tell64 or lo_seek64)?
>>>
>>> Adding anything inside pqFunctionCall is useless, unless we were to add
>>> an int64 variant to PQArgBlock, which isn't a good idea because it will
>>> be an ABI break. The functions in fe-lobj.c have to set up the int64
>>> value as if it were pass-by-reference, which means dealing with
>>> endianness concerns there.
>>
>> I just want to make sure you guy's point.
>>
>> We do not modify pqFunctionCall. That means PQfn does not accept
>> PQArgBlock.isint != 0 and PQArgBlock.len == 8 case. If a PQfn caller
>> wants to send 64-bit integer, it should set PQArgBlock.isint = 0 and
>> PQArgBlock.len = 8 and set data pass-by-reference. Endianness should
>> be taken care by the PQfn caller. Also we do not modify fe-misc.c
>> because there's no point to add pqPutint64/pqGetint64(they are called
>> from pqFunctionCall in the patch).
>>
> Yes, it is exactly what I suggested.
Thanks for the confirmation!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
