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 →
-
Remove all the special-case code for INT64_IS_BUSTED, per decision that
- 901be0fad403 9.0.0 cited