> The problem is that there is not a clean hierarchy of SQL types, but for
> many cases one could either convert the operands to int4 or float8 and
> then numeric(?) and then convert back. At least the conversion operators
> check for overflow, which is better than the current situation. And
> precision wise it cannot be much worse: after all, large integer
> constants already end up as floats. Is the SQL standard pedantic about
> this?
Yes. The implicit "big integer" -> float8 done in the scanner is an
expedient hack to keep from rejecting the large number entirely, but is
likely not in the spirit of the SQL standard.
The Right Way would have us set the large integer string to int8 and/or
numeric, but the scanner does not know about those types at the moment,
mostly for historical reasons.
If we made the scanner aware of integers larger than int4, we would have
to choose between int8 (not supported on all platforms, but mostly OK)
and numeric, which is markedly slower to process and handle. I recall
that Tom Lane had the proposal to use a more loosely categorized "some
kind of numeric type" in the scanner, postponing the hard assignment of
type to later in the parser. That might get around the performance
issues, since numeric would only be used if the context required it.
- Thomas
