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