Oh my. I am running on 1.37.
I see that you have made a change 5 months ago in github. That might help! Thanks! On Mon, Dec 9, 2024 at 10:52 AM Mihai Budiu <mbu...@gmail.com> wrote: > 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 >
