Hi Ingo, 1) I think you are right, the table path should be fully-qualified.
2) I think this is also a good point. The SHOW CREATE TABLE only aims to print DDL for the tables registered using SQL CREATE TABLE DDL. If a table is registered using Table API, e.g. `StreamTableEnvironment#createTemporaryView(String, DataStream)`, currently it's not possible to print DDL for such tables. I think we should point it out in the FLIP. Best, Jark On Mon, 15 Feb 2021 at 21:33, Ingo Bürk <i...@ververica.com> wrote: > Hi all, > > I have a couple questions about the SHOW CREATE TABLE statement. > > 1) Contrary to the example in the FLIP I think the returned DDL should > always have the table identifier fully-qualified. Otherwise the DDL depends > on the current context (catalog/database), which could be surprising, > especially since "the same" table can behave differently if created in > different catalogs. > 2) How should this handle tables which cannot be fully characterized by > properties only? I don't know if there's an example for this yet, but > hypothetically this is not currently a requirement, right? This isn't as > much of a problem if this syntax is SQL-client-specific, but if it's > general Flink SQL syntax we should consider this (one way or another). > > > Regards > Ingo > > On Fri, Feb 12, 2021 at 3:53 PM Timo Walther <twal...@apache.org> wrote: > > > Hi Shengkai, > > > > thanks for updating the FLIP. > > > > I have one last comment for the option `table.execution.mode`. Should we > > already use the global Flink option `execution.runtime-mode` instead? > > > > We are using Flink's options where possible (e.g. `pipeline.name` and > > `parallism.default`) why not also for batch/streaming mode? > > > > The description of the option matches to the Blink planner behavior: > > > > ``` > > Among other things, this controls task scheduling, network shuffle > > behavior, and time semantics. > > ``` > > > > Regards, > > Timo > > > > On 10.02.21 06:30, Shengkai Fang wrote: > > > Hi, guys. > > > > > > I have updated the FLIP. It seems we have reached agreement. Maybe we > > can > > > start the vote soon. If anyone has other questions, please leave your > > > comments. > > > > > > Best， > > > Shengkai > > > > > > Rui Li <lirui.fu...@gmail.com>于2021年2月9日 周二下午7:52写道： > > > > > >> Hi guys, > > >> > > >> The conclusion sounds good to me. > > >> > > >> On Tue, Feb 9, 2021 at 5:39 PM Shengkai Fang <fskm...@gmail.com> > wrote: > > >> > > >>> Hi, Timo, Jark. > > >>> > > >>> I am fine with the new option name. > > >>> > > >>> Best, > > >>> Shengkai > > >>> > > >>> Timo Walther <twal...@apache.org>于2021年2月9日 周二下午5:35写道： > > >>> > > >>>> Yes, `TableEnvironment#executeMultiSql()` can be future work. > > >>>> > > >>>> @Rui, Shengkai: Are you also fine with this conclusion? > > >>>> > > >>>> Thanks, > > >>>> Timo > > >>>> > > >>>> On 09.02.21 10:14, Jark Wu wrote: > > >>>>> I'm fine with `table.multi-dml-sync`. > > >>>>> > > >>>>> My previous concern about "multi" is that DML in CLI looks like > > >> single > > >>>>> statement. > > >>>>> But we can treat CLI as a multi-line accepting statements from > > >> opening > > >>> to > > >>>>> closing. > > >>>>> Thus, I'm fine with `table.multi-dml-sync`. > > >>>>> > > >>>>> So the conclusion is `table.multi-dml-sync` (false by default), and > > >> we > > >>>> will > > >>>>> support this config > > >>>>> in SQL CLI first, will support it in > > >> TableEnvironment#executeMultiSql() > > >>>> in > > >>>>> the future, right? > > >>>>> > > >>>>> Best, > > >>>>> Jark > > >>>>> > > >>>>> On Tue, 9 Feb 2021 at 16:37, Timo Walther <twal...@apache.org> > > >> wrote: > > >>>>> > > >>>>>> Hi everyone, > > >>>>>> > > >>>>>> I understand Rui's concerns. `table.dml-sync` should not apply to > > >>>>>> regular `executeSql`. Actually, this option makes only sense when > > >>>>>> executing multi statements. Once we have a > > >>>>>> `TableEnvironment.executeMultiSql()` this config could be > > >> considered. > > >>>>>> > > >>>>>> Maybe we can find a better generic name? Other platforms will also > > >>> need > > >>>>>> to have this config option, which is why I would like to avoid a > SQL > > >>>>>> Client specific option. Otherwise every platform has to come up > with > > >>>>>> this important config option separately. > > >>>>>> > > >>>>>> Maybe `table.multi-dml-sync` `table.multi-stmt-sync`? Or other > > >>> opinions? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Timo > > >>>>>> > > >>>>>> On 09.02.21 08:50, Shengkai Fang wrote: > > >>>>>>> Hi, all. > > >>>>>>> > > >>>>>>> I think it may cause user confused. The main problem is we have > no > > >>>> means > > >>>>>>> to detect the conflict configuration, e.g. users set the option > > >> true > > >>>> and > > >>>>>>> use `TableResult#await` together. > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> Shengkai. > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> -- > > >> Best regards! > > >> Rui Li > > >> > > > > > > > >
