Re: 64-bit API for large object
От | Tatsuo Ishii |
---|---|
Тема | Re: 64-bit API for large object |
Дата | |
Msg-id | 20120930.100730.1159304632702304349.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: 64-bit API for large object (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: