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
