Re: 64-bit API for large object

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: 64-bit API for large object
Дата
Msg-id CADyhKSUa9y9pEhCEuYnm_OpNj=wtbH4xgJ3X75nSvHeG5RZz-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 64-bit API for large object  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: 64-bit API for large object
Re: 64-bit API for large object
Список pgsql-hackers
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?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: 64-bit API for large object
Следующее
От: Amit kapila
Дата:
Сообщение: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown