From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, anzai(at)sraoss(dot)co(dot)jp, nagata(at)sraoss(dot)co(dot)jp |
Subject: | Re: 64-bit API for large object |
Date: | 2012-09-21 09:49:57 |
Message-ID: | CADyhKSWn8PyhYkgA4O1LzQzzLs0P2jMVJ0ZjEDW8mqLb+gzkVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/9/21 Tatsuo Ishii <ishii(at)postgresql(dot)org>:
>>>> 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.
>
> 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?
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2012-09-21 10:02:03 | Re: 64-bit API for large object |
Previous Message | Tatsuo Ishii | 2012-09-21 09:39:28 | Re: 64-bit API for large object |