Re: [HACKERS] Numeric with '-'
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Numeric with '-' |
Дата | |
Msg-id | 2016.951123651@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Numeric with '-' (Brian Hirt <bhirt@mobygames.com>) |
Ответы |
Re: [HACKERS] Numeric with '-'
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: