Re: 64-bit API for large object

Tatsuo Ishii <ishii@postgresql.org>

From: Tatsuo Ishii <ishii@postgresql.org>
To: ishii@postgresql.org
Cc: tgl@sss.pgh.pa.us, kaigai@kaigai.gr.jp, pgsql-hackers@postgresql.org, anzai@sraoss.co.jp, nagata@sraoss.co.jp
Date: 2012-09-22T00:22:25Z
Lists: 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).

Oops. There's no such a function pqGetint64 in the patch. 64-bit int
case is taken care inside pqGetint.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove all the special-case code for INT64_IS_BUSTED, per decision that