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-21T10:11:29Z
Lists: pgsql-hackers
2012/9/21 Tatsuo Ishii <ishii@postgresql.org>: >>>>> 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? > 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? 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