Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> ... It seems pretty
> clear to me that anything of the form [0-9]+ is an integer, something with
> an 'e' in it is a float, and something with only digits and decimal points
> is numeric.
So 123456789012345678901234567890 is an integer? Not on the machines
I use. Nor do I want to restrict 1234567890.1234567890e20 or 1e500
to be considered always and only floats; the first will drop precision
and the second will overflow, whereas they are both perfectly useful
as numeric.
What I'd originally hoped was that we could postpone determining the
type of a numeric literal until we saw where it was going to be used,
as in Hiroshi's INSERT into t (numdata) values (-1234567890.1234567);
example. Unfortunately that doesn't work in some other fairly
obvious cases, like SELECT 1.2 + 3.4; you just plain don't have any
other cues except the sizes and precisions of the constants to resolve
the type here.
So the original code was right, I think, to the extent that it looked
at the precision and size of the constant to select a default type
for the constant. But it wasn't right to lose the numeric-ness of the
constant altogether when it doesn't fit in a double. What I'm testing
now is code that generates either INT4, FLOAT8, or NUMERIC depending
on precision and size --- but never UNKNOWN, which is what you'd get
before with more than 17 digits.
regards, tom lane