Hello all,
I was wondering if there's any virtue in creating an operator like UNNEST
by having a similar implementation like that of SqlUnnestOperator.
(SqlExplodeOperator maybe)
The functionalities are close but there are nuances that I have not
discovered yet.
My approach was kind of a hack :
Clone the class SqlUnnestOperator -> rename the SqlFunctionalOperator name
as "EXPLODE" and rename return builder.add("$unnest", SqlTypeName.ANY)
.nullable(true).build() in the inferReturnType to "$explode" -> then check
if call.getKind() within unparseCall is UNNEST -> if yes then SqlUtil.
unparseFunctionSyntax(SqlStdOperatorTable.EXPLODE, writer, call, false).
NOTE: I have also tried creating a new kind EXPLODE and then followed the
above step, both of them work.
As Julian had pointed out about semantics and how everything within Calcite
should be in Calcite's dialect, I feel there could be antipatterns in my
approach.
Could any of you please point me to where I might be going wrong? How could
I make this more robust?
(If any of you are wondering why I am doing this then this is what I want
to achieve - "SELECT * FROM UNNEST(ARRAY['1', '2'])" can be written as
"SELECT * FROM EXPLODE(ARRAY['1', '2'])" in an appropriate dialect, like
Spark for example)
Thank you for your time!
Best,
Soumyadeep.
