Re: [HACKERS] numeric data type on 6.5

> > I'm looking at this right now. I had coded in a fallback to FLOAT8 for
> > the integer types because at the time that was the only other useful
> > numeric type. However, I'm going to try changing the code to leave a
> > failed INTx token as a string of unspecified type, which would be
> > typed and converted later using the automatic coersion mechanism.
> That would be good as far as it goes, but what about cases with a
> decimal point in 'em? Converting to float and then to numeric will
> lose precision.
> I'm inclined to think you should prevent the parser from converting
> *any* numeric constant out of string form until it knows the target data
> type.
> (IIRC, INT8 has problems similar to NUMERIC's...)

Right. Here is a patch which tries to do something right for most
cases. For the "integer" token (numbers w/o a decimal point) it keeps
the token as a string if the conversion to int4 fails. I split the
"real" token into "decimal" (w/o exponent) and "real"; at the moment
"decimal" is forced to become a float8 if there are fewer than 18
characters in the string, but there may be a more robust strategy to
be had.

When a numeric token is kept as a string, the parser requires some
typing context to handle the string later, otherwise it will complain.
But that is probably better than silently swallowing numeric data and
possibly mishandling it.

Seems to do OK with numeric tokens of unspecified type which will
become int8 and numeric in the parser. There may be some edge-effect
cases (e.g. decimal data with 17 characters) which aren't quite right.

Comments?

- Tom

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California