Yes, the appropriate solution would be to check the expressions being projected and not to trigger your rule for projections you can't handle. For example, check out CassandraProjectRule#matches which validates that only field references are being projected.
-- Michael Mior [email protected] 2017-11-28 15:39 GMT-05:00 Christian Tzolov <[email protected]>: > Hey there, > > I have another question related to > > handling > > spatial ( > or > any) functions in custom adapter implementations. > > For e > > example the > > rel > . plan for the following query > ( > with > > spatial function > ) > > > EXPLAIN PLAN FOR SELECT > "city", > ST_Point( > cast("loc" [0] AS DOUBLE), > cast("loc" [1] AS DOUBLE) > ) > FROM "geode"."Zips" > LIMIT > 10; > > will produce plan like this: > > > GeodeToEnumerableConverterRel > GeodeProjectRel(city=[$1], EXPR$1=[*ST_POIN*T(CAST(ITEM($2, 0)):DOUBLE, > CAST(ITEM($2, 1)):DOUBLE)]) > GeodeSortRel(fetch=[10]) > GeodeTableScanRel(table=[[geode, Zips]]) > > Given that my GeodeProjectRel implementation doesn't know about the > *ST_POIN*T this should fail? Or somehow get ignored in my case. > > What is the correct way to handle such cases? > > Perhaps in my Project rule i should make sure that projection with function > expression should not be matched so it falls back to the the > EnumerableProjection? > > Thanks, > Christian >
