Brian Hirt <bhirt@mobygames.com> writes:
> "select -1234567890.123456;" also works while
> "select -1234567890.1234567;" does not. That
> extra character just seems to push things over
> the edge.
> It almost seems like there is some sort of length
> restriction somewhere in the parser.
Indeed there is, and you'll find it at src/backend/parser/scan.l
line 355 (in current sources). The lexer backs off from "float
constant" to "unspecified string constant" in order to avoid losing
precision from conversion to float. Which is fine, except that
without any cue that the constant is numeric, the parser is unable
to figure out what to do with the '-' operator.
I've been ranting about this in a recent pghackers thread ;-).
The lexer shouldn't have to commit to a conversion to float8
in order to report that a token looks like a numeric literal.
The resulting error message
ERROR: Unable to convert left operator '-' from type 'unknown'
isn't exactly up to a high standard of clarity either; what it
really means is "unable to choose a unique left operator '-'
for type 'unknown'", and it ought to suggest adding an explicit
cast. I'll see what I can do about that. But the right way to
fix the fundamental problem is still under debate.
In the meantime you can provide the parser a clue with an
explicit cast:
play=> select -1234567890.1234567::numeric; ?column?
-----------------
-1234567890.12346
(1 row)
This still seems a little broken though, since it looks like the
constant's precision is getting truncated to 15 digits; presumably
there's a coercion to float happening in there somewhere, but I
don't understand where at the moment...
A few minutes later: yes I do: there's no unary minus operator
defined for type numeric, so the parser does the best it can
by applying float8um instead. Jan?
regards, tom lane
