You are in essence asking whether there can be any difference between FLOAT and DOUBLE. If the code generated by Calcite cares, then there can​ be such a difference.
However, I believe that Calcite already assumes implicitly that these two types are the same. This means that it is very dangerous for other platforms to assume that Calcite will keep the types distinct. But perhaps some pieces in Calcite keep the distinction, while others don't, and if you only use the ones that keep the distinction, then you are fine. For example, as far as I can tell, expression simplification assumes that these two types are the same. If Calcite assumes some semantics for some construct (e.g., FLOAT being the same as DOUBLE), it is quite brittle for a target platform or user of calcite to assume that Calcite won't use this assumption while rewriting the program. This makes it even more important to write down explicitly the assumptions that Calcite makes, e.g., the semantics of types, or the semantics of casts (which is an issue I have been working on lately). The existing documentation is too sparse to be able to tell. In essence I am asking for a SPEC of the SQL language compiled by Calcite. It is fine for Calcite to say "the semantics of FLOAT is target-specific", but in that case it should not make optimizations assuming that FLOAT is the same as DOUBLE. Mihai ________________________________ From: Paul Jackson <[email protected]> Sent: Thursday, October 26, 2023 2:51 PM To: [email protected] <[email protected]> Subject: Re: Removing FLOAT 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
