Re: 64-bit API for large object

Kohei KaiGai <kaigai@kaigai.gr.jp>

From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org, anzai@sraoss.co.jp, nagata@sraoss.co.jp
Date: 2012-09-21T15:46:23Z
Lists: pgsql-hackers
2012/9/21 Tatsuo Ishii <ishii@postgresql.org>:
>> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>>> My preference is nothing are changed both pg_getmsgint64() of the backend
>>> and routines under PQfn() of the libpq. Isn't it unavailable to deliver int64-
>>> value "after" the endian translation on the caller side?
>>
>> Right.  If we had to change anything on the backend side, it would mean
>> we had a wire protocol change, which is even less acceptable than a
>> libpq ABI change.
>
> The patch does not touch pg_getmsgint64() and I don't think we are not
> going have a wire protocol change.
>
It's also uncertain what portion does Tom said "right" for...

What I pointed out is this patch adds a special case handling on pqFunctionCall3
of libpq to fetch 64bit-integer from PQArgBlock->u.ptr and adjust endian orders.
It is never the topic on backend side.

It is not a technical problem, but I feel a bit strange coding style.
So, I don't want to against it so much.

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)?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove all the special-case code for INT64_IS_BUSTED, per decision that