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