> > No fair only doing it for float8; int4 has the same trouble.
> Au contraire: int representation has no risk of loss of precision.
> It does risk overflow, but we can detect that reliably, and in fact
> scan.l already takes care of that scenario.
Right, but why bother doing it there and then having to propagate the
"int4 or string" code into the backend? Right now, we mark it as an
string constant of unknown characteristics if it is too large for an
int4, but that isn't the right thing for long numerics since we are
throwing away valuable info. And using the scan.l heuristic to filter
out large values for things like OIDs is probably cheating a bit ;)
> If we allow ints to retain their current representation, then the
> manipulations currently done in gram.y don't need to change. All
> that's needed is to invoke the proper typinput function after we've
> decided what type we really want to convert a T_Float to. T_Float
> would act kind of like UNKNOWN-type string constants, except that
> the knowledge that the string looks numeric-ish could be used in
> type selection heuristics.
So a replacement for T_Float would carry the "long string with decimal
point" info, and a replacement for T_Integer would carry the "long
string with digits only" info. And we would continue to use T_Float
and T_Integer deeper in the backend to carry converted values.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California