Are you sure that you need your constant values to be instances of RexLiteral? A call to a 'constructor function' might do just as well.
In Calcite's geospatial support, there is no literal for the GEOMETRY type. Expressions such as ST_PointFromText('POINT(-71.064544 42.28787)') are commonplace and (I believe) are handled OK by Calcite's constant reduction. On Thu, May 9, 2024 at 9:51 AM Luke VanderHart <luke.vanderh...@gmail.com> wrote: > > Hi all, > > I'm evaluating if Calcite is a good fit as a query planner for my database > project, and would appreciate some high-level pointers on where to look in > the source to figure out how to do what I need. Or, alternatively, > confirmation if it's not feasible. > > My system is relational but not SQL, and I would like to work with concrete > values which don't map cleanly to any existing SQL types. I am happy > defining my own equality, hash and comparison semantics, and would like > them to work with Calcite's existing equality/comparison operators, as well > as my own user defined functions. > > The type system mostly seems quite flexible, but where I'm running into > trouble is actually using them as inputs to queries. For example, I'd like > to create a filter to return only rows with a field value equal to one of > these custom values, but I can't use RexCall(SqlOperator, RexField, > RexLiteral) because RexLiteral explicitly only supports a limited set of > SQL types. > > 1. I don't need full compatibility: I am ok if my custom types only work > with backends I write. > 2. The whole system is in-process, so no need to worry about serialization > or conversion. > 2. I plan on using the algebra directly, so no parser support is needed. > > Can anyone give any pointers to what classes/interfaces I should look at > for this kind of use case? I don't need a full example or anything, just an > indication of where in the (rather extensive) type system to start digging. > Ideally in a place that preserves as many of Calcite's > built-in optimizations as possible. > > Many thanks, and I appreciate your work on this clearly very sophisticated > project. > > - Luke VanderHart