> > 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?
> I'd suggest backing off one more place on the length of string you will
> try to convert to a float8. Since the test is strlen() <= 17, you
> actually can have at most 16 digits (there must be a decimal point in
> there too). But IEEE float is only good to 16-and-change digits; I'm
> not sure I'd want to assume that the 16th digit will always be
> reproduced exactly. 15 digits would be safer.
Yeah. I'd chosen 17 to get sign+decimal+15digits...
> It could still break if the C library's float<=>string conversion
> routines are sloppy :-(. I suppose you're interested in preserving
> the info that "this constant looks numeric-ish" to assist in type
> resolution heuristics? Otherwise the value could be left in string
> form till later.
> Is there any value in marking the constant as a numeric token, yet
> leaving its specific value as a string until after type resolution
> is done?
Possibly. I didn't think too hard about it, but had assumed that doing
much more than I did would propagate back into the parser, which I
didn't want to tackle this close to release.
- Tom
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
