I am only proposing to remove it from the IR. The type would still be accepted by the parser, just represented as DOUBLE. No SQL programs would need to change. Just treat it the same way DECIMAL and NUMERIC are handled; there is only one representation for both.
Julian's solution is the first I thought about, and it certainly can be done. There are two reasons that I proposed a radical approach: * if the type isn't there you cannot make mistakes anymore treating it wrong * even more importantly, if third party users of Calcite (e.g., let's say a system like Spark) assumed that FLOAT is something else (in Spark it's the same as REAL as far as I can tell), they will now find out that their assumption is wrong, and can take corrective actions. Both solution would entail a non-trivial amount of work, so I am trying to avoid working on the wrong one. Mihai ________________________________ From: Julian Hyde <[email protected]> Sent: Thursday, October 26, 2023 3:04 PM To: [email protected] <[email protected]> Subject: Re: Removing FLOAT Removing a type that is in the SQL standard is not practical. The best way to deal with the confusion is to state the rules again. If there are a few inconsistencies in the code, fix the inconsistencies. REAL is a 32 bit float (similar to Java float); DOUBLE is a 64 bit float (similar to Java double); Use of FLOAT is not recommended, but it is currently equivalent to DOUBLE. > On Oct 26, 2023, at 2:51 PM, Paul Jackson > <[email protected]> wrote: > > Doesn't having two types help distinguish which type is in the source > database for platforms that support both? A call to > org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that > distinction. I don't know offhand whether there are databases that require a > CAST when converting from double to float. Would that be important to know > before deciding? > -Paul > On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu > <[email protected]> wrote: > > Hello, > > It turns out that there is a lot of confusion in Calcite about what FLOAT is. > I have filed an issue about it: > https://issues.apache.org/jira/browse/CALCITE-6074 > > It seems that the intent is for FLOAT to be an exact alias of DOUBLE. > If that's the case, we can remove a lot of code and prevent further > confusions by just removing FLOAT as a SqlTypeName and using DOUBLE > everywhere starting in the parser. The situation is very similar with DECIMAL > and NUMERIC. > > This will also prevent a lot of bugs in third party code that uses Calcite, > since they cannot misinterpret what FLOAT is. > > If you agree that this is the right thing, I will submit a PR which marks > FLOAT as @Deprecated and removes all its uses in the codebase. > > Mihai >
