Re: 64-bit API for large object

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: kaigai(at)kaigai(dot)gr(dot)jp, ishii(at)postgresql(dot)org, 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-21 23:18:55
Message-ID: 20120922.081855.205768120292894863.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2012-09-21 23:59:07 Re: CREATE SCHEMA IF NOT EXISTS
Previous Message Milton Labanda 2012-09-21 22:14:48 PLV8JS