Re: 64-bit API for large object

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: kaigai(at)kaigai(dot)gr(dot)jp
Cc: ishii(at)postgresql(dot)org, 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-21 10:02:03
Message-ID: 20120921.190203.1904700559388873270.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>> I thought pgPutInt64() takes care of endianness. No?
>>>>
>>> It works inside of the PGfn(), when isint = 1 towards pointer data type.
>>> In my sense, it is a bit problem specific solution.
>>>
>>> So, I'd like to see other person's opinion here.
>>
>> I think we cannot change this because we want to keep the counter part
>> backend side function pq_getmsgint64() as it is (the function is not
>> part of the patch).
>>
> My opinion is lo_lseek64() and lo_tell64() should handle endian translation
> prior and next to PQfn() invocation; to avoid the int64 specific case-handling
> inside of PQfn() that can be called by other applications.
>
> Am I missing something?

So what do you want to do with pq_getmsgint64()? It exactly does the
same thing as pqPutInt64(), just in opposit direction. Do you want to
change pq_getmsgint64()? Or add new function in backend?
--
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 Kohei KaiGai 2012-09-21 10:11:29 Re: 64-bit API for large object
Previous Message Kohei KaiGai 2012-09-21 09:49:57 Re: 64-bit API for large object