I can’t tell whether you are intending to contribute EXPLODE or do it on a private branch. You don’t make a case for what EXPLODE could do, so I presume the latter.
UNNEST is a unique function. Its implementation is (unfortunately but necessarily) spread over many files. Copy-pasting it to make a new function seems like a bad idea, because you would be multiplying a mess. I don’t know what you’re trying to achieve but I would lean on the existing facilities (UDFs, table functions, adding syntactic sugar if necessary). Julian > On Jun 3, 2023, at 2:45 AM, Soumyadeep Mukhopadhyay <[email protected]> > wrote: > > 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.
