Re: 64-bit API for large object
От | Kohei KaiGai |
---|---|
Тема | Re: 64-bit API for large object |
Дата | |
Msg-id | CADyhKSXtRHy4F8kWK_y_KhPB3u1ZfQi6rM=DqcvFh0Rspnx+2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 64-bit API for large object (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: 64-bit API for large object
|
Список | pgsql-hackers |
2012/9/22 Tatsuo Ishii <ishii@postgresql.org>: > 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). > Yes, it is exactly what I suggested. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: