> 2012/9/22 Tatsuo Ishii <is...@postgresql.org>: >> Tom, Kaigai, >> >>> Kohei KaiGai <kai...@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 for the confirmation! -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
