That's exactly the kind of input I'm looking for! Functions certainly could
work for me, as long as the optimization propagates just as well as it
would with a literal (and sounds like yes, if that's the basis for
geospatial support).
On Thu, May 9, 2024 at 1:55 PM Julian Hyde <jh...@apache.org> wrote:
> 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
>
