> > > 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.
This seems like a perfect approach.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
