Re: 64-bit API for large object
От | Tatsuo Ishii |
---|---|
Тема | Re: 64-bit API for large object |
Дата | |
Msg-id | 20120921.190203.1904700559388873270.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: 64-bit API for large object (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: 64-bit API for large object
|
Список | pgsql-hackers |
>>>> 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? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: