> 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
