From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, anzai(at)sraoss(dot)co(dot)jp, nagata(at)sraoss(dot)co(dot)jp |
Subject: | Re: 64-bit API for large object |
Date: | 2012-09-22 19:44:44 |
Message-ID: | CADyhKSXtRHy4F8kWK_y_KhPB3u1ZfQi6rM=DqcvFh0Rspnx+2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/9/22 Tatsuo Ishii <ishii(at)postgresql(dot)org>:
> Tom, Kaigai,
>
>> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-22 21:39:28 | Re: alter enum add value if not exists |
Previous Message | Dean Rasheed | 2012-09-22 19:02:41 | Re: Proof of concept: auto updatable views [Review of Patch] |