Re: Configuring for 64-bit integer date/time storage?
От | Thomas Lockhart |
---|---|
Тема | Re: Configuring for 64-bit integer date/time storage? |
Дата | |
Msg-id | 3C9E1ECD.92B9D9AC@fourpalms.org обсуждение исходный текст |
Ответ на | Configuring for 64-bit integer date/time storage? (Thomas Lockhart <thomas@fourpalms.org>) |
Список | pgsql-hackers |
> I'd suggest --enable-bigint-datetimes, or possibly > --enable-int8-datetimes, to make it clearer that 64-bit-int support > is needed. Hmm. The *feature* it is enabling is "consistant precision through the range of allowed values". I'd rather move in the direction of qualitative description, than toward the direction of explicit underlying implementation. > 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. Right. The default could be changed sometime later. ... > No strong feeling here, but I suspect Peter will say that it should > error out. There is code in c.h which links the HAVE_xxx definitions to compiler types, etc. But is *also* defines INT64_IS_BUSTED as a catchall for having not found any int64 types at all. And it isn't until this point that anyone knows for sure that there is not an int64 type. At least in the current code, at least afaict. And at that point, we don't allow things to "error out" in the sense of allowing "#error" or something similar. > 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. Sure. The problem is in doing that in two different places for two different reasons, where it *should* happen in one place (or at least at similar stages of the process). The possibilities you have raised don't have that happening so istm that we are still missing something. As you point out, Peter will probably have a suggestion ;) - Thomas
В списке pgsql-hackers по дате отправления: