From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | kaigai(at)kaigai(dot)gr(dot)jp |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, 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 09:27:39 |
Message-ID: | 20120921.182739.1482959347454343889.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I think Tom's point is, there are tons of applications which define
>> their own "int64_t" (at least in 2005).
>> Also pg_config.h has:
>>
>> #define HAVE_STDINT_H 1
>>
>> and this suggests that PostgreSQL adopts to platforms which does not
>> have stdint.h. If so, we need to take care of such platforms anyway.
>>
> OK, it makes me clear. It might be helpful a source code comment
> to remain why we used self defined datatype here.
Ok.
> 2012/9/21 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>>> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr
>>> is a pointer to 64-bit integer and actual data is placed somewhere
>>> else.
>>
>> Yeah, I think we have to do it like that. Changing the size of
>> PQArgBlock would be a libpq ABI break, which IMO is sufficiently painful
>> to kill this whole proposal. Much better a little localized ugliness
>> in fe-lobj.c.
>>
> Hmm, I see. Please deliver the 64bit integer argument as reference,
> and don't forget endian translations here.
I thought pgPutInt64() takes care of endianness. No?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-09-21 09:34:12 | Re: 64-bit API for large object |
Previous Message | Rural Hunter | 2012-09-21 09:16:46 | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |