Re: 64-bit API for large object

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <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 08:25:43
Message-ID: CADyhKSVs318QeXwyRQdJ7DgzgOzgTmYa89EaWh=B8nnNFhtebA@mail.gmail.com
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.

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.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2012-09-21 08:33:53 Re: 64-bit API for large object
Previous Message Shigeru HANADA 2012-09-21 08:24:59 Re: proposal - assign result of query to psql variable