Re: 64-bit API for large object
Tatsuo Ishii <ishii@postgresql.org>
From: Tatsuo Ishii <ishii@postgresql.org>
To: kaigai@kaigai.gr.jp
Cc: ishii@postgresql.org, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org, anzai@sraoss.co.jp, nagata@sraoss.co.jp
Date: 2012-09-21T10:02:03Z
Lists: pgsql-hackers
>>>> 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? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.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