> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers