What are you trying to achieve? Indeed, today the Calcite parser assumes that numeric literals with an exponent are floating point.
I don't think the standard mandates a specific type based on the syntax of the literal. I am pretty sure Calcite can parse literals above Long.MAX_VALUE, since some Decimal literals may be larger. After parsing all literals are stored as Java BigDecimal value, which has unbounded precision. In general, if you want a specific type for a SQL expression, you should write it down explicitly in the code, using a CAST. The rules for implicit casts are also unspecified and vary from database to database. Mihai ________________________________ From: Stephen Carlin <scar...@cloudera.com.INVALID> Sent: Monday, December 9, 2024 10:40 AM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: literal "type" issues in my database Hi, I'm having some literal type issues when trying to use Calcite with my database. I have quite a few of them, and I thought perhaps it was my database not dealing with the SQL standard correctly, but the latest one I hit seems, well, inconsistent within Calcite. When I run the literal 123.45 through Calcite, it is producing a decimal type for me, which is fine. However, if I pass in the literal 1e32 through Calcite, it gives me a double. I noticed a comment somewhere which states Calcite cannot handle integers over the bigint max. The comment was from 2006, so it doesn't look like it will be addressed anytime soon? Has anyone dealt with this? If so, how did you handle it? I'm not sure this can be handled well. I did try to change the parser to create my own NumericLiteral. However, when I used a negative integer out of range, it used a static SqlLiteral create function embedded in the Calcite jar file and had similar issues. I do have a hack around this in my code that gets around this post-validation time, so I won't be addressing this in Calcite in the near future, but has anyone thought about this in general? I should also mention (since I alluded to it at the beginning of my message) that my database treats char literals as a "varchar(maxint)" type (Calcite treats it as char) and tinyints like "2" as a tinyint (calcite treats this as int). Thanks, Steve
