Re: 64-bit API for large object
Tatsuo Ishii <ishii@postgresql.org>
From: Tatsuo Ishii <ishii@postgresql.org>
To: alvherre@2ndquadrant.com
Cc: kaigai@kaigai.gr.jp, anzai@sraoss.co.jp, pgsql-hackers@postgresql.org
Date: 2012-09-30T01:07:30Z
Lists: pgsql-hackers
> Excerpts from Kohei KaiGai's message of jue sep 27 01:01:18 -0300 2012: > >> * I have a question. What is the meaning of INT64_IS_BUSTED? >> It seems to me a marker to indicate a platform without 64bit support. >> However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce >> says as follows: >> | Remove all the special-case code for INT64_IS_BUSTED, per decision that >> | we're not going to support that anymore. > > Yeah, I think we should just get rid of those bits. I don't remember > seeing *any* complaint when INT64_IS_BUSTED was removed, which means > nobody was using that code anyway. Ok. > Now there is one more problem in this area which is that the patch > defined a new type pg_int64 for frontend code (postgres_ext.h). This > seems a bad idea to me. We already have int64 defined in c.h. Should > we expose int64 to postgres_ext.h somehow? Should we use standard- > mandated int64_t instead? One way would be to have a new configure > check for int64_t, and if that type doesn't exist, then just don't > provide the 64 bit functionality to frontend. This has been already explained in upthread: http://archives.postgresql.org/pgsql-hackers/2012-09/msg00447.php -- 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