Re: Configuring for 64-bit integer date/time storage?
От | Tom Lane |
---|---|
Тема | Re: Configuring for 64-bit integer date/time storage? |
Дата | |
Msg-id | 9935.1016993378@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Configuring for 64-bit integer date/time storage? (Thomas Lockhart <thomas@fourpalms.org>) |
Список | pgsql-hackers |
Thomas Lockhart <thomas@fourpalms.org> writes: > 1) For the ./configure command line option, does > --enable-integer-datetimes seem OK, or could someone suggest a better > choice? --enable-integer-datetimes is a longer string than any of the > other options, so a less wordy possibility may be better. I'd suggest --enable-bigint-datetimes, or possibly --enable-int8-datetimes, to make it clearer that 64-bit-int support is needed. A more interesting question is which way should be the default; might it make sense to default to bigint datetimes on machines where it's possible to do so? Without performance info it's probably too soon to decide, though. > 2) Actually using integer date/time storage depends on whether 64-bit > integers are really supported. So although they may be enabled, it may > not be supported. Should ./configure error out at that point, or should > things gracefully (silently?) configure to use the existing floating > point implementation? See (3). No strong feeling here, but I suspect Peter will say that it should error out. > 3) ./configure checks for several different styles of 64-bit integers to > see what is actually supported. But it does not control whether an > overall "yes we have some kind of 64-bit integer" flag gets defined. So > detecting an inconsistancy in enabling 64-bit integer storage on > machines without 64-bit integers seems to be out of the scope of > ./configure. Correct? No. configure must define either HAVE_LONG_INT_64 or HAVE_LONG_LONG_INT_64 to get the int8 support to work. If neither gets defined, you should conclude that bigint datetimes won't work. regards, tom lane
В списке pgsql-hackers по дате отправления: