> 2012/9/21 Tatsuo Ishii <ishii@postgresql.org>:
>>>>>> 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.
>>>>
>>>> I think we cannot change this because we want to keep the counter part
>>>> backend side function pq_getmsgint64() as it is (the function is not
>>>> part of the patch).
>>>>
>>> My opinion is lo_lseek64() and lo_tell64() should handle endian translation
>>> prior and next to PQfn() invocation; to avoid the int64 specific case-handling
>>> inside of PQfn() that can be called by other applications.
>>>
>>> Am I missing something?
>>
>> So what do you want to do with pq_getmsgint64()? It exactly does the
>> same thing as pqPutInt64(), just in opposit direction. Do you want to
>> change pq_getmsgint64()? Or add new function in backend?
>>
> My preference is nothing are changed both pg_getmsgint64() of the backend
> and routines under PQfn() of the libpq. Isn't it unavailable to deliver int64-
> value "after" the endian translation on the caller side?
I am confused.
>>> My opinion is lo_lseek64() and lo_tell64() should handle endian translation
>>> prior and next to PQfn() invocation; to avoid the int64 specific case-handling
>>> inside of PQfn() that can be called by other applications.
Why do we need this? If PQArgBlock.isint != 0, it treats input data as
integer anyway. So I don't see any use case other than "int64 specific
case-handling" if isint != 0 and len == 8. If you have other use case
for isint != 0 and len == 8, please show it.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
