Yes, the idea is to convert the QueryOperation tree into a proper/compilable query. To be honest I didn't think it could be done differently, sorry if I wasn't clear enough. Yes, it is very much like SqlNode#toSqlString you mentioned. I'll add an example of a single QueryOperation tree to the FLIP.
I tried to focus only on the public contracts, not on the implementation details. I mentioned Expressions, because this requires changing semi-public interfaces in BuiltinFunctionDefinitions. Hope this makes it clearer. Regards, Dawid On Thu, 16 Nov 2023 at 12:12, Benchao Li <libenc...@apache.org> wrote: > Sorry that I wasn't expressing it clearly. > > Since the FLIP talks about two things: ResolvedExpression and > QueryOperation, and you have illustrated how to serialize > ResolvedExpression into SQL string. I'm wondering how you'll gonna to > convert QueryOperation into SQL string. > > I was thinking that you proposed to convert the QueryOperation tree > into a "complete runnable SQL statement", e.g. > > ProjectQueryOperation(x,y)->FilterQueryOperation(z>10)->TableSourceQueryOperation(T), > we'll get "SELECT x, y FROM T WHERE z > 10". > Maybe I misread it, maybe you just meant to convert each > QueryOperation into a row-level SQL string instead the whole tree into > a complete SQL statement. > > The idea of translating whole QueryOperation tree into SQL statement > may come from my experience of Apache Calcite, there is a > SqlImplementor[1] which convert a RelNode tree into SqlNode, and > further we can use SqlNode#toSqlString to unparse it into SQL string. > I would assume that most of our QueryOperations are much like the > abstraction of Calcite's RelNode, with some exceptions such as > PlannerQueryOperation. > > [1] > https://github.com/apache/calcite/blob/1537555596f8994831ad015af4b9036aa01ebf78/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L141 > > Dawid Wysakowicz <wysakowicz.da...@gmail.com> 于2023年11月16日周四 16:24写道： > > > > I think the FLIP covers all public contracts that are necessary to be > > discussed at that level. > > > > If you meant you could not find a method that would be called to trigger > > the translation then it is already there. It's just not implemented yet: > > QueryOperation#asSerializableString[1]. As I mentioned this is mostly a > > follow up to previous work. > > > > Regards, > > Dawid > > > > [1] > > > https://github.com/apache/flink/blob/d18a4bfe596fc580f8280750fa3bfa22007671d9/flink-table/flink-table-api-java/src/main/java/org/apache/flink/table/operations/QueryOperation.java#L46 > > > > On Wed, 15 Nov 2023 at 16:36, Benchao Li <libenc...@apache.org> wrote: > > > > > +1 for the idea of choosing SQL as the serialization format for > > > QueryOperation, thanks for Dawid for driving this FLIP. > > > > > > Regarding the implementation, I didn't see the proposal for how to > > > translate QueryOperation to SQL yet, am I missing something? Or the > > > FLIP is still in preliminary state, you just want to gather ideas > > > about whether to use SQL or something else as the serialization format > > > for QueryOperation? > > > > > > Dawid Wysakowicz <dwysakow...@apache.org> 于2023年11月15日周三 19:34写道： > > > > > > > > Hi, > > > > I would like to propose a follow-up improvement to some of the work > that > > > > has been done over the years to the Table API. I posted the proposed > > > > changes in the FLIP-393. I'd like to get to know what others think of > > > > choosing SQL as the serialization format for QueryOperations. > > > > Regards, > > > > Dawid Wysakowicz > > > > > > > > [1] https://cwiki.apache.org/confluence/x/vQ2ZE > > > > > > > > > > > > -- > > > > > > Best, > > > Benchao Li > > > > > > > -- > > Best, > Benchao Li >
