Hi all, If there is no question related to this FLIP, we will start the voting thread on 3/6 (Monday). thank you all.
Best Regards, Ran Tao https://github.com/chucheng92 Ran Tao <chucheng...@gmail.com> 于2023年3月1日周三 17:40写道： > Hi, Timo. thanks. > > I have copied the content of docs and updated the FLIP. > > Thanks for your advice about consistency(ILIKE). > Because calcite already support parse ILIKE and exist > SqlLibraryOperators.ILIKE(which means it's not std). > It's will not difficult to support it, and we just need to support it in > table & sql api and not need to change sql keywords or Parser.jj. > > However, in flink docs, we may let users know that this is not standard, > just for better use. > > Best Regards, > Ran Tao > > > Timo Walther <twal...@apache.org> 于2023年2月28日周二 22:23写道： > >> Hi Ran Tao, >> >> Thanks for working on this FLIP. The FLIP is in a pretty good shape >> already and I don't have much to add. >> >> Will we also support ILIKE in queries? Or is this a pure DDL >> expressions? For consistency, we should support it in SELECT and Table >> API as well. I hope this is not too much effort. I hope everybody is >> aware that ILIKE is not standard compliant but seems to be used by a >> variety of vendors. >> >> > Because it may be modified under discuss, we put it on the google >> docs. please see FLIP-297: Improve Auxiliary Sql Statements Docs >> >> This comment confused me. It would be nice to have the Wiki page as the >> single source of truth and abandon the Google doc. In the past we used >> Google Docs more but nowadays I support using only the Wiki to avoid any >> confusion. >> >> Regards, >> Timo >> >> >> On 28.02.23 12:51, Ran Tao wrote: >> > thanks Sergey, sounds good. >> > You can add in FLIP ticket[1]. >> > >> > [1] https://issues.apache.org/jira/browse/FLINK-31256 >> > >> > Best Regards, >> > Ran Tao >> > https://github.com/chucheng92 >> > >> > >> > Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月28日周二 19:44写道： >> > >> >>>> Currently I think we can load from the jar and check the services >> file to >> >>>> get the connector type. but is it necessary we may continue to >> discuss. >> >>>> Hi, Sergey, WDYT？ >> >> >> >> Another idea is FactoryUtil#discoverFactories and >> >> check if it implements DynamicTableSourceFactory or >> DynamicTableSinkFactory >> >> with versions it could be trickier... >> >> Moreover it seems the version could be a part of the name sometimes[1]. >> >> I think name and type could be enough or please correct me if I'm wrong >> >> >> >>>> or can we open a single ticket under this FLIP? >> >> I have a relatively old jira issue[2] for showing connectors with a >> poc pr. >> >> Could I propose to move this jira issue as a subtask under the FLIP >> one and >> >> revive it? >> >> >> >> [1] >> >> >> >> >> https://github.com/apache/flink/blob/161014149e803bfd1d3653badb230b2ed36ce3cb/flink-table/flink-table-common/src/main/java/org/apache/flink/table/factories/Factory.java#L65-L69 >> >> [2] https://issues.apache.org/jira/browse/FLINK-25788 >> >> >> >> On Tue, Feb 28, 2023 at 11:56 AM Ran Tao <chucheng...@gmail.com> >> wrote: >> >> >> >>> Hi, Jark. thanks. >> >>>> About ILIKE >> >>> I have updated the FLIP for ILIKE support (Including existing >> showTables >> >> & >> >>> showColumns how to change). >> >>> >> >>>> About show connectors @Sergey, >> >>> Currently I think we can load from the jar and check the services >> file to >> >>> get the connector type. but is it necessary we may continue to >> discuss. >> >>> Hi, Sergey, WDYT？or can we open a single ticket under this FLIP? >> >>> >> >>> >> >>> Best Regards, >> >>> Ran Tao >> >>> >> >>> >> >>> Jark Wu <imj...@gmail.com> 于2023年2月28日周二 17:45写道： >> >>> >> >>>> Besides, if we introduce the ILIKE, we should also add this feature >> for >> >>>> the previous SHOW with LIKE statements. They should be included in >> this >> >>>> FLIP. >> >>>> >> >>>> Best, >> >>>> Jark >> >>>> >> >>>>> 2023年2月28日 17:40，Jark Wu <imj...@gmail.com> 写道： >> >>>>> >> >>>>> Hi Ran, >> >>>>> >> >>>>> Could you add descriptions about what’s the behavior and differences >> >>>> between the LIKE and ILIKE? >> >>>>> >> >>>>> Besides, I don’t see the SHOW CONNECTOR syntax and description and >> >> how >> >>>> it works in the FLIP. Is it intended to be included in this FLIP? >> >>>>> >> >>>>> Best, >> >>>>> Jark >> >>>>> >> >>>>> >> >>>>>> 2023年2月28日 10:58，Ran Tao <chucheng...@gmail.com> 写道： >> >>>>>> >> >>>>>> Hi, guys. thanks for advices. >> >>>>>> >> >>>>>> allow me to make a small summary: >> >>>>>> >> >>>>>> 1.Support ILIKE >> >>>>>> 2.Using catalog api to support show operations >> >>>>>> 3.Need a dedicated FLIP try to support INFORMATION_SCHEMA >> >>>>>> 4.Support SHOW CONNECTORS >> >>>>>> >> >>>>>> If there are no other questions, i will try to start a VOTE for >> this >> >>>> FLIP. >> >>>>>> WDYT? >> >>>>>> >> >>>>>> Best Regards, >> >>>>>> Ran Tao >> >>>>>> >> >>>>>> >> >>>>>> Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月27日周一 21:12写道： >> >>>>>> >> >>>>>>> Hi Jark, >> >>>>>>> >> >>>>>>> thanks for your comment. >> >>>>>>> >> >>>>>>>> Considering they >> >>>>>>>> are orthogonal and information schema requires more complex >> design >> >>> and >> >>>>>>>> discussion, it deserves a separate FLIP >> >>>>>>> I'm ok with a separate FLIP for INFORMATION_SCHEMA. >> >>>>>>> >> >>>>>>>> Sergey, are you willing to contribute this FLIP? >> >>>>>>> Seems I need to have more research done for that. >> >>>>>>> I would try to help/contribute here >> >>>>>>> >> >>>>>>> >> >>>>>>> On Mon, Feb 27, 2023 at 3:46 AM Ran Tao <chucheng...@gmail.com> >> >>> wrote: >> >>>>>>> >> >>>>>>>> HI, Jing. thanks. >> >>>>>>>> >> >>>>>>>> @about ILIKE, from my collections of some popular engines founds >> >>> that >> >>>>>>> just >> >>>>>>>> snowflake has this syntax in show with filtering. >> >>>>>>>> do we need to support it? if yes, then current some existed show >> >>>>>>> operations >> >>>>>>>> need to be addressed either. >> >>>>>>>> @about ShowOperation with like. it's a good idea. yes, two >> >>> parameters >> >>>> for >> >>>>>>>> constructor can work. thanks for your advice. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Best Regards, >> >>>>>>>> Ran Tao >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Jing Ge <j...@ververica.com.invalid> 于2023年2月27日周一 06:29写道： >> >>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> @Aitozi >> >>>>>>>>> >> >>>>>>>>> This is exactly why LoD has been introduced: to avoid exposing >> >>>> internal >> >>>>>>>>> structure(2nd and lower level API). >> >>>>>>>>> >> >>>>>>>>> @Jark >> >>>>>>>>> >> >>>>>>>>> IMHO, there is no conflict between LoD and "High power-to-weight >> >>>> ratio" >> >>>>>>>>> with the given example, List.subList() returns List interface >> >>> itself, >> >>>>>>> no >> >>>>>>>>> internal or further interface has been exposed. After offering >> >>>>>>>>> tEvn.getCatalog(), "all" methods in Catalog Interface have been >> >>>>>>> provided >> >>>>>>>> by >> >>>>>>>>> TableEnvironment(via getCatalog()). From user's perspective and >> >>>>>>>> maintenance >> >>>>>>>>> perspective there is no/less difference between providing them >> >>>> directly >> >>>>>>>> via >> >>>>>>>>> TableEnvironment or via getCatalog(). They are all exposed. >> Using >> >>>>>>>>> getCatalog() will reduce the number of boring wrapper methods, >> >> but >> >>> on >> >>>>>>> the >> >>>>>>>>> other hand not every method in Catalog needs to be exposed, so >> >> the >> >>>>>>> number >> >>>>>>>>> of wrapper methods would be limited/less, if we didn't expose >> >>>> Catalog. >> >>>>>>>>> Nevertheless, since we already offered getCatalog(), it makes >> >> sense >> >>>> to >> >>>>>>>>> continue using it. The downside is the learning effort for users >> >> - >> >>>> they >> >>>>>>>>> have to know that listDatabases() is hidden in Catalog, go to >> >>> another >> >>>>>>>>> haystack and then find the needle in there. >> >>>>>>>>> >> >>>>>>>>> +1 for Information schema with a different FLIP. From a design >> >>>>>>>> perspective, >> >>>>>>>>> information schema should be the first choice for most cases and >> >>> easy >> >>>>>>> to >> >>>>>>>>> use. Catalog, on the other hand, will be more powerful and offer >> >>> more >> >>>>>>>>> advanced features. >> >>>>>>>>> >> >>>>>>>>> Best regards, >> >>>>>>>>> Jing >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Sat, Feb 25, 2023 at 3:57 PM Jark Wu <imj...@gmail.com> >> >> wrote: >> >>>>>>>>> >> >>>>>>>>>> Hi Sergey, >> >>>>>>>>>> >> >>>>>>>>>> I think INFORMATION_SCHEMA is a very interesting idea, and I >> >> hope >> >>> we >> >>>>>>>> can >> >>>>>>>>>> support it. However, it doesn't conflict with the idea of >> >>> auxiliary >> >>>>>>>>>> statements. I can see different benefits of them. The >> >> information >> >>>>>>>> schema >> >>>>>>>>>> provides powerful and flexible capabilities but needs to learn >> >> the >> >>>>>>>>> complex >> >>>>>>>>>> entity relationship[1]. The auxiliary SQL statements are super >> >>> handy >> >>>>>>>> and >> >>>>>>>>>> can resolve most problems, but they offer limited features. >> >>>>>>>>>> >> >>>>>>>>>> I can see almost all the mature systems support both of them. I >> >>>> think >> >>>>>>>> it >> >>>>>>>>>> also makes sense to support both of them in Flink. Considering >> >>> they >> >>>>>>>>>> are orthogonal and information schema requires more complex >> >> design >> >>>>>>> and >> >>>>>>>>>> discussion, it deserves a separate FLIP. Sergey, are you >> willing >> >>> to >> >>>>>>>>>> contribute this FLIP? >> >>>>>>>>>> >> >>>>>>>>>> Best, >> >>>>>>>>>> Jark >> >>>>>>>>>> >> >>>>>>>>>> [1]: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>> >> >>> >> >> >> https://docs.databricks.com/sql/language-manual/sql-ref-information-schema.html >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Fri, 24 Feb 2023 at 22:43, Ran Tao <chucheng...@gmail.com> >> >>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Thanks John. >> >>>>>>>>>>> >> >>>>>>>>>>> It seems that most people prefer the information_schema >> >>>>>>>> implementation. >> >>>>>>>>>>> information_schema does have more benefits (however, the show >> >>>>>>>> operation >> >>>>>>>>>> is >> >>>>>>>>>>> also an option and supplement). >> >>>>>>>>>>> Otherwise, the sql syntax and keywords may be changed >> >> frequently. >> >>>>>>>>>>> Of course, it will be more complicated than the extension of >> >> the >> >>>>>>> show >> >>>>>>>>>>> operation. >> >>>>>>>>>>> It is necessary to design various tables in >> information_schema, >> >>>>>>>> which >> >>>>>>>>>> may >> >>>>>>>>>>> take a period of effort. >> >>>>>>>>>>> >> >>>>>>>>>>> I will try to design the information_schema and integrate it >> >> with >> >>>>>>>>> flink. >> >>>>>>>>>>> This may be a relatively big feature for me. I hope you guys >> >> can >> >>>>>>> give >> >>>>>>>>>>> comments and opinions later. >> >>>>>>>>>>> Thank you all. >> >>>>>>>>>>> >> >>>>>>>>>>> Best Regards, >> >>>>>>>>>>> Ran Tao >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> John Roesler <vvcep...@apache.org> 于2023年2月24日周五 21:53写道： >> >>>>>>>>>>> >> >>>>>>>>>>>> Hello Ran, >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks for the FLIP! >> >>>>>>>>>>>> >> >>>>>>>>>>>> Do you mind if we revisit the topic of doing this by adding >> an >> >>>>>>>>>>> Information >> >>>>>>>>>>>> schema? The SHOW approach requires modifying the >> >> parser/language >> >>>>>>>> for >> >>>>>>>>>>> every >> >>>>>>>>>>>> gap we identify. On the flip side, an Information schema is >> >> much >> >>>>>>>>> easier >> >>>>>>>>>>> to >> >>>>>>>>>>>> discover and remember how to use, and the ability to run >> >> queries >> >>>>>>> on >> >>>>>>>>> it >> >>>>>>>>>> is >> >>>>>>>>>>>> quite valuable for admins. It’s also better for Flink >> >>>>>>> maintainers, >> >>>>>>>>>>> because >> >>>>>>>>>>>> the information tables’ schemas can be evolved over time just >> >>>>>>> like >> >>>>>>>>>>> regular >> >>>>>>>>>>>> tables, whereas every change to a SHOW statement would be a >> >>>>>>>> breaking >> >>>>>>>>>>>> change. >> >>>>>>>>>>>> >> >>>>>>>>>>>> I understand that it may seem like a big effort, but we’re >> >>>>>>>> proposing >> >>>>>>>>>>> quite >> >>>>>>>>>>>> a big extension to the space of SHOW statement, so it seems >> >>>>>>>>> appropriate >> >>>>>>>>>>> to >> >>>>>>>>>>>> take the opportunity and migrate to a better framework rather >> >>>>>>> than >> >>>>>>>>>>>> incrementally building on (and tying us even more firmly to) >> >> the >> >>>>>>>>>> existing >> >>>>>>>>>>>> approach. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks for your consideration, >> >>>>>>>>>>>> John >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Fri, Feb 24, 2023, at 05:58, Sergey Nuyanzin wrote: >> >>>>>>>>>>>>> thanks for explanation >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> But it's not clear to me what exactly >> >>>>>>>>>>>>>> you want to display? Is it the name of the plugin? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I was thinking about name, type (source/sink) and may be >> >>>>>>> version >> >>>>>>>>> (not >> >>>>>>>>>>>> sure >> >>>>>>>>>>>>> if it's possible right now) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Fri, Feb 24, 2023 at 12:46 PM Ran Tao < >> >>>>>>> chucheng...@gmail.com> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> Hi, Sergey. thanks. first step we can support filtering for >> >>>>>>> show >> >>>>>>>>>>>> operations >> >>>>>>>>>>>>>> in this FLIP try to align other engines. >> >>>>>>>>>>>>>> If we want to support describe other objects, of course we >> >>>>>>> need >> >>>>>>>> to >> >>>>>>>>>>>> design >> >>>>>>>>>>>>>> how to get these metadatas or informations and >> printAsStyle. >> >>>>>>> (So >> >>>>>>>>> it >> >>>>>>>>>>>> maybe >> >>>>>>>>>>>>>> need another FLIP for more details). >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Does it make sense to add support for connectors e.g. show >> >>>>>>>>>>>>>>> {sink|source|all} connectors? >> >>>>>>>>>>>>>> I think we can support it, currently flink do support some >> >>>>>>>>>> operations >> >>>>>>>>>>>> only >> >>>>>>>>>>>>>> for flink itself such as showJobs. But it's not clear to me >> >>>>>>> what >> >>>>>>>>>>> exactly >> >>>>>>>>>>>>>> you want to display? Is it the name of the plugin? >> >>>>>>>>>>>>>> Just Like: >> >>>>>>>>>>>>>> Kafka >> >>>>>>>>>>>>>> Hudi >> >>>>>>>>>>>>>> Files >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Best Regards, >> >>>>>>>>>>>>>> Ran Tao >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月24日周五 >> >> 19:11写道： >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thanks for driving the FLIP >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I have a couple of questions >> >>>>>>>>>>>>>>> Am I right that INFORMATION_SCHEMA mentioned by Timo[1] >> is >> >>>>>>>> out >> >>>>>>>>> of >> >>>>>>>>>>>> scope >> >>>>>>>>>>>>>> of >> >>>>>>>>>>>>>>> this FLIP? >> >>>>>>>>>>>>>>> I noticed there are some support of it in >> >>>>>>>>>>>> Spark[2]/Hive[3]/Snowflake[4] >> >>>>>>>>>>>>>> and >> >>>>>>>>>>>>>>> others >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Does it make sense to add support for connectors e.g. show >> >>>>>>>>>>>>>>> {sink|source|all} connectors? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> [1] >> >>>>>>>>>>> >> >> https://lists.apache.org/thread/2g108qlfwbhb56wnoc5qj0yq29dvq1vv >> >>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/SPARK-16452 >> >>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/HIVE-1010 >> >>>>>>>>>>>>>>> [4] >> >> https://docs.snowflake.com/en/sql-reference/info-schema >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Fri, Feb 24, 2023 at 4:19 AM Jark Wu <imj...@gmail.com >> > >> >>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Hi Jing, >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> we'd better reduce the dependency chain and follow the >> >>>>>>> Law >> >>>>>>>>> of >> >>>>>>>>>>>>>>>> Demeter(LoD, clean code). >> >>>>>>>>>>>>>>>>> Adding a new method in TableEnvironment is therefore >> >>>>>>>> better >> >>>>>>>>>> than >> >>>>>>>>>>>>>>> calling >> >>>>>>>>>>>>>>>> an API chain >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> I think I don't fully agree that LoD is a good practice. >> >>>>>>>>>>> Actually, I >> >>>>>>>>>>>>>>> would >> >>>>>>>>>>>>>>>> prefer to keep the API clean and concise. >> >>>>>>>>>>>>>>>> This is also the Java Collection Framework design >> >>>>>>> principle >> >>>>>>>>> [1]: >> >>>>>>>>>>>> "High >> >>>>>>>>>>>>>>>> power-to-weight ratio". Otherwise, >> >>>>>>>>>>>>>>>> it will explode the API interfaces with different >> >>>>>>>> combinations >> >>>>>>>>>> of >> >>>>>>>>>>>>>>> methods. >> >>>>>>>>>>>>>>>> Currently, TableEnvironment >> >>>>>>>>>>>>>>>> already provides 60+ methods. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> IMO, with the increasing methods of accessing and >> >>>>>>>> manipulating >> >>>>>>>>>>>>>> metadata, >> >>>>>>>>>>>>>>>> they can be extracted to >> >>>>>>>>>>>>>>>> a separate interface, where we can add richer methods. >> >>>>>>> This >> >>>>>>>>> work >> >>>>>>>>>>>> can be >> >>>>>>>>>>>>>>>> aligned with the >> >>>>>>>>>>>>>>>> CatalogManager interface (FLIP-295) [2]. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Best, >> >>>>>>>>>>>>>>>> Jark >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> [1]: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>> >> >>> >> >> >> https://stackoverflow.com/questions/7568819/why-no-tail-or-head-method-in-list-to-get-last-or-first-element >> >>>>>>>>>>>>>>>> [2]: >> >>>>>>>>>>>> >> >>> https://lists.apache.org/thread/9bnjblgd9wvrl75lkm84oo654c4lqv70 >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On Fri, 24 Feb 2023 at 10:38, Aitozi < >> >>>>>>> gjying1...@gmail.com> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>>>>>> Thanks for the nice proposal, Ran. >> >>>>>>>>>>>>>>>>> Regarding this api usage, I have some discussion >> >>>>>>> with >> >>>>>>>>>>> @twalthr >> >>>>>>>>>>>>>>> before >> >>>>>>>>>>>>>>>>> as here < >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>> >> https://github.com/apache/flink/pull/15137#issuecomment-1356124138 >> >>>>>>>>> >> >>>>>>>>>>>>>>>>> Personally, I think leaking the Catalog to the user side >> >>>>>>>> is >> >>>>>>>>>> not >> >>>>>>>>>>>>>>> suitable, >> >>>>>>>>>>>>>>>>> since there are some read/write operations in the >> >>>>>>> Catalog, >> >>>>>>>>> the >> >>>>>>>>>>>>>>>>> TableEnvironment#getCatalog will expose all of them to >> >>>>>>> the >> >>>>>>>>>> user >> >>>>>>>>>>>> side. >> >>>>>>>>>>>>>>> So >> >>>>>>>>>>>>>>>> I >> >>>>>>>>>>>>>>>>> learned to add a new api in TableEnvironment to reduce >> >>>>>>>>>> reliance >> >>>>>>>>>>> on >> >>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> current TableEnvironment#getCatalog. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>>>> Aitozi >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Ran Tao <chucheng...@gmail.com> 于2023年2月23日周四 23:44写道： >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Hi, JingSong, Jing. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> thank for sharing your opinions. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> What you say makes sense, both approaches have pros >> >>>>>>> and >> >>>>>>>>>> cons. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> If it is a modification of `TableEnvrionment`, such as >> >>>>>>>>>>>>>>>>>> listDatabases(catalog). It is actually consistent with >> >>>>>>>> the >> >>>>>>>>>>> other >> >>>>>>>>>>>>>>>>> overloaded >> >>>>>>>>>>>>>>>>>> methods before, >> >>>>>>>>>>>>>>>>>> and defining this method means that TableEnvrionment >> >>>>>>>> does >> >>>>>>>>>>>> provide >> >>>>>>>>>>>>>>> this >> >>>>>>>>>>>>>>>>>> capability (rather than relying on the functionality >> >>>>>>> of >> >>>>>>>>>>> another >> >>>>>>>>>>>>>>> class). >> >>>>>>>>>>>>>>>>>> The disadvantage is that api changes may be required, >> >>>>>>>> and >> >>>>>>>>>> may >> >>>>>>>>>>>>>>> continue >> >>>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>> be modified in the future. >> >>>>>>>>>>>>>>>>>> But from the TableEnvrionment itself, it really >> >>>>>>> doesn't >> >>>>>>>>> pay >> >>>>>>>>>>>>>> attention >> >>>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>> how the underlying layer is implemented. >> >>>>>>>>>>>>>>>>>> (Although it is actually taken from the catalogManager >> >>>>>>>> at >> >>>>>>>>>>>> present, >> >>>>>>>>>>>>>>> this >> >>>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>> another question) >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Judging from the current dependencies, >> >>>>>>>>> flink-table-api-java >> >>>>>>>>>>>>>> strongly >> >>>>>>>>>>>>>>>>> relies >> >>>>>>>>>>>>>>>>>> on flink-table-common to use various common classes >> >>>>>>> and >> >>>>>>>>>>>> interfaces, >> >>>>>>>>>>>>>>>>>> especially the catalog interface. >> >>>>>>>>>>>>>>>>>> So we can extract various metadata information in the >> >>>>>>>>>> catalog >> >>>>>>>>>>>>>> through >> >>>>>>>>>>>>>>>>>> `tEnv.getCatalog`. >> >>>>>>>>>>>>>>>>>> The advantage is that it will not cause api >> >>>>>>>> modification, >> >>>>>>>>>> but >> >>>>>>>>>>>> this >> >>>>>>>>>>>>>>>> method >> >>>>>>>>>>>>>>>>>> of use breaks LoD. >> >>>>>>>>>>>>>>>>>> In fact, the current flink-table-api-java design is >> >>>>>>>>>> completely >> >>>>>>>>>>>>>> bound >> >>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>> catalog interface. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> If the mandatory modification of PublicApi is >> >>>>>>>> constrained >> >>>>>>>>>> (may >> >>>>>>>>>>>> be >> >>>>>>>>>>>>>>>>> modified >> >>>>>>>>>>>>>>>>>> again and later), I tend to use `tEnv.getCatalog` >> >>>>>>>>> directly, >> >>>>>>>>>>>>>> otherwise >> >>>>>>>>>>>>>>>>>> It would actually be more standard to add overloaded >> >>>>>>>>> methods >> >>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>> `TableEnvrionment`. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Another question, can the later capabilities of >> >>>>>>>>>>>> TableEnvrionment be >> >>>>>>>>>>>>>>>>>> implemented through SupportXXX? >> >>>>>>>>>>>>>>>>>> In order to solve the problem that the method needs to >> >>>>>>>> be >> >>>>>>>>>>> added >> >>>>>>>>>>>> in >> >>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>> future. This kind of usage occurs frequently in flink. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Looking forward to your other considerations, >> >>>>>>>>>>>>>>>>>> and also try to wait to see if there are other >> >>>>>>> relevant >> >>>>>>>>> API >> >>>>>>>>>>>>>> designers >> >>>>>>>>>>>>>>>> or >> >>>>>>>>>>>>>>>>>> committers to provide comments. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Best Regards, >> >>>>>>>>>>>>>>>>>> Ran Tao >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Jing Ge <j...@ververica.com.invalid> 于2023年2月23日周四 >> >>>>>>>>> 18:58写道： >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> Hi Jingson, >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see my >> >>>>>>> reply >> >>>>>>>>>> below. >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 10:16 AM Jingsong Li < >> >>>>>>>>>>>>>>> jingsongl...@gmail.com >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Hi Jing Ge, >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> First, flink-table-common contains all common >> >>>>>>>> classes >> >>>>>>>>> of >> >>>>>>>>>>>> Flink >> >>>>>>>>>>>>>>>> Table, >> >>>>>>>>>>>>>>>>>>>> I think it is hard to bypass its dependence. >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> If any time when we use flink-table-api-java, we >> >>>>>>> have >> >>>>>>>> to >> >>>>>>>>>>> cross >> >>>>>>>>>>>>>>>> through >> >>>>>>>>>>>>>>>>>>> flink-table-api-java and use flink-table-common, we >> >>>>>>>>> should >> >>>>>>>>>>>>>>> reconsider >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>>> design of these two modules and how >> >>>>>>> interfaces/classes >> >>>>>>>>> are >> >>>>>>>>>>>>>>> classified >> >>>>>>>>>>>>>>>>>> into >> >>>>>>>>>>>>>>>>>>> those modules. >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Secondly, almost all methods in Catalog looks >> >>>>>>> useful >> >>>>>>>>> to >> >>>>>>>>>>> me, >> >>>>>>>>>>>> so >> >>>>>>>>>>>>>> if >> >>>>>>>>>>>>>>>> we >> >>>>>>>>>>>>>>>>>>>> are following LoD, we should add all methods again >> >>>>>>>> to >> >>>>>>>>>>>>>>>>>>>> TableEnvironment. I think it is redundant. >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> That is the enlarged issue I mentioned previously. A >> >>>>>>>>>> simple >> >>>>>>>>>>>>>>> solution >> >>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>>> move Catalog to the top level API. The fact is that >> >>>>>>> a >> >>>>>>>>>>> catalog >> >>>>>>>>>>>>>>> package >> >>>>>>>>>>>>>>>>>>> already exists in flink-table-api-java but the >> >>>>>>> Catalog >> >>>>>>>>>>>> interface >> >>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>>> flink-table-common. I don't know the historical >> >>>>>>>> context >> >>>>>>>>> of >> >>>>>>>>>>>> this >> >>>>>>>>>>>>>>>> design. >> >>>>>>>>>>>>>>>>>>> Maybe you could share some insight with us? Thanks >> >>>>>>> in >> >>>>>>>>>>> advance. >> >>>>>>>>>>>>>>> Beyond >> >>>>>>>>>>>>>>>>>> that, >> >>>>>>>>>>>>>>>>>>> there should be other AOP options but need more time >> >>>>>>>> to >> >>>>>>>>>>>> figure it >> >>>>>>>>>>>>>>>> out. >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> And, this API chain does not look deep. >> >>>>>>>>>>>>>>>>>>>> - >> >>>>>>>>>>>>>>> >> >>>>>>>>> >> "tEnv.getCatalog(tEnv.getCurrentCatalog()).get().listDatabases()" >> >>>>>>>>>>>>>>>>>>>> looks a little complicated. The complex part is >> >>>>>>>> ahead. >> >>>>>>>>>>>>>>>>>>>> - If we have a method to get Catalog directly, can >> >>>>>>>> be >> >>>>>>>>>>>> simplify >> >>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>>>> "tEnv.catalog().listDatabase()", this is simple. >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> Commonly, it will need more effort to always follow >> >>>>>>>> LoD, >> >>>>>>>>>> but >> >>>>>>>>>>>> for >> >>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> top >> >>>>>>>>>>>>>>>>>>> level facade API like TableEnvironment, both the API >> >>>>>>>>>>>> developer, >> >>>>>>>>>>>>>> API >> >>>>>>>>>>>>>>>>>>> consumer and the project itself from a long-term >> >>>>>>>>>> perspective >> >>>>>>>>>>>> will >> >>>>>>>>>>>>>>>>> benefit >> >>>>>>>>>>>>>>>>>>> from sticking to LoD. Since we already have the >> >>>>>>>>>>>> getCatalog(String >> >>>>>>>>>>>>>>>>>> catalog) >> >>>>>>>>>>>>>>>>>>> method in TableEnvironment, it also makes sense to >> >>>>>>>>> follow >> >>>>>>>>>>> your >> >>>>>>>>>>>>>>>>>> suggestion, >> >>>>>>>>>>>>>>>>>>> if we only want to limit/avoid public API changes. >> >>>>>>> But >> >>>>>>>>>>> please >> >>>>>>>>>>>> be >> >>>>>>>>>>>>>>>> aware >> >>>>>>>>>>>>>>>>>> that >> >>>>>>>>>>>>>>>>>>> we will have all known long-term drawbacks because >> >>>>>>> of >> >>>>>>>>> LoD >> >>>>>>>>>>>>>>>>>>> violation, especially the cross modules violation. I >> >>>>>>>>> just >> >>>>>>>>>>>> checked >> >>>>>>>>>>>>>>> all >> >>>>>>>>>>>>>>>>>>> usages of getCatalog(String catalog) in the master >> >>>>>>>>> branch. >> >>>>>>>>>>>>>>> Currently >> >>>>>>>>>>>>>>>>>> there >> >>>>>>>>>>>>>>>>>>> are very limited calls. It is better to pay >> >>>>>>> attention >> >>>>>>>> to >> >>>>>>>>>> it >> >>>>>>>>>>>>>> before >> >>>>>>>>>>>>>>> it >> >>>>>>>>>>>>>>>>>> goes >> >>>>>>>>>>>>>>>>>>> worse. Just my 2 cents. :) >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Best, >> >>>>>>>>>>>>>>>>>>>> Jingsong >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 4:47 PM Jing Ge >> >>>>>>>>>>>>>>> <j...@ververica.com.invalid >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> Hi Jingson, >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> Thanks for the knowledge sharing. IMHO, it looks >> >>>>>>>>> more >> >>>>>>>>>>>> like a >> >>>>>>>>>>>>>>>> design >> >>>>>>>>>>>>>>>>>>>>> guideline question than just avoiding public API >> >>>>>>>>>> change. >> >>>>>>>>>>>>>> Please >> >>>>>>>>>>>>>>>>>> correct >> >>>>>>>>>>>>>>>>>>>> me >> >>>>>>>>>>>>>>>>>>>>> if I'm wrong. >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> Catalog is in flink-table-common module and >> >>>>>>>>>>>> TableEnvironment >> >>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>>>>> flink-table-api-java. Depending on how and where >> >>>>>>>>> those >> >>>>>>>>>>>>>> features >> >>>>>>>>>>>>>>>>>>> proposed >> >>>>>>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>>>>> this FLIP will be used, we'd better reduce the >> >>>>>>>>>>> dependency >> >>>>>>>>>>>>>> chain >> >>>>>>>>>>>>>>>> and >> >>>>>>>>>>>>>>>>>>>> follow >> >>>>>>>>>>>>>>>>>>>>> the Law of Demeter(LoD, clean code) [1]. Adding >> >>>>>>> a >> >>>>>>>>> new >> >>>>>>>>>>>> method >> >>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>>>>> TableEnvironment is therefore better than >> >>>>>>> calling >> >>>>>>>> an >> >>>>>>>>>> API >> >>>>>>>>>>>>>> chain. >> >>>>>>>>>>>>>>>> It >> >>>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>>>> also >> >>>>>>>>>>>>>>>>>>>>> more user friendly for the caller, because there >> >>>>>>>> is >> >>>>>>>>> no >> >>>>>>>>>>>> need >> >>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>>> understand >> >>>>>>>>>>>>>>>>>>>>> the internal structure of the called API. The >> >>>>>>>>> downside >> >>>>>>>>>>> of >> >>>>>>>>>>>>>> doing >> >>>>>>>>>>>>>>>>> this >> >>>>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>>>>> that we might have another issue with the >> >>>>>>> current >> >>>>>>>>>>>>>>>> TableEnvironment >> >>>>>>>>>>>>>>>>>>>> design - >> >>>>>>>>>>>>>>>>>>>>> the TableEnvironment interface got enlarged with >> >>>>>>>>> more >> >>>>>>>>>>>> wrapper >> >>>>>>>>>>>>>>>>>> methods. >> >>>>>>>>>>>>>>>>>>>> This >> >>>>>>>>>>>>>>>>>>>>> is a different issue that could be solved with >> >>>>>>>>>> improved >> >>>>>>>>>>>>>>>> abstraction >> >>>>>>>>>>>>>>>>>>>> design >> >>>>>>>>>>>>>>>>>>>>> in the future. After considering pros and cons, >> >>>>>>> if >> >>>>>>>>> we >> >>>>>>>>>>>> want to >> >>>>>>>>>>>>>>> add >> >>>>>>>>>>>>>>>>>> those >> >>>>>>>>>>>>>>>>>>>>> features now, I would prefer following LoD than >> >>>>>>>> API >> >>>>>>>>>>> chain >> >>>>>>>>>>>>>>> calls. >> >>>>>>>>>>>>>>>>>> WDYT? >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>>>>>>>>> Jing >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> [1] >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>> >> >>> >> >> >> https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85 >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 6:26 AM Ran Tao < >> >>>>>>>>>>>>>> chucheng...@gmail.com >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> Hi Jingsong. thanks. i got it. >> >>>>>>>>>>>>>>>>>>>>>> In this way, there is no need to introduce new >> >>>>>>>> API >> >>>>>>>>>>>> changes. >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> Best Regards, >> >>>>>>>>>>>>>>>>>>>>>> Ran Tao >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> Jingsong Li <jingsongl...@gmail.com> >> >>>>>>>>> 于2023年2月23日周四 >> >>>>>>>>>>>>>> 12:26写道： >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Hi Ran, >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> I mean we can just use >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >> TableEnvironment.getCatalog(getCurrentCatalog).get().listDatabases(). >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> We don't need to provide new apis just for >> >>>>>>>>> utils. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Best, >> >>>>>>>>>>>>>>>>>>>>>>> Jingsong >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 12:11 PM Ran Tao < >> >>>>>>>>>>>>>>>>> chucheng...@gmail.com> >> >>>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Hi Jingsong, thanks. >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> The implementation of these statements in >> >>>>>>>>>>>>>>>>> TableEnvironmentImpl >> >>>>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>>>>>> called >> >>>>>>>>>>>>>>>>>>>>>>>> through the catalog api. >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> but it does support some new override >> >>>>>>>> methods >> >>>>>>>>> on >> >>>>>>>>>>> the >> >>>>>>>>>>>>>>>> catalog >> >>>>>>>>>>>>>>>>>> api >> >>>>>>>>>>>>>>>>>>>> side, >> >>>>>>>>>>>>>>>>>>>>>>> and >> >>>>>>>>>>>>>>>>>>>>>>>> I will update it later. Thank you. >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> e.g. >> >>>>>>>>>>>>>>>>>>>>>>>> TableEnvironmentImpl >> >>>>>>>>>>>>>>>>>>>>>>>> @Override >> >>>>>>>>>>>>>>>>>>>>>>>> public String[] listDatabases() { >> >>>>>>>>>>>>>>>>>>>>>>>> return catalogManager >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> .getCatalog(catalogManager.getCurrentCatalog()) >> >>>>>>>>>>>>>>>>>>>>>>>> .get() >> >>>>>>>>>>>>>>>>>>>>>>>> .listDatabases() >> >>>>>>>>>>>>>>>>>>>>>>>> .toArray(new String[0]); >> >>>>>>>>>>>>>>>>>>>>>>>> } >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Best Regards, >> >>>>>>>>>>>>>>>>>>>>>>>> Ran Tao >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Jingsong Li <jingsongl...@gmail.com> >> >>>>>>>>>>> 于2023年2月23日周四 >> >>>>>>>>>>>>>>>> 11:47写道： >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> +1 for the proposal. >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> I am confused about "Proposed >> >>>>>>>>> TableEnvironment >> >>>>>>>>>>> SQL >> >>>>>>>>>>>>>> API >> >>>>>>>>>>>>>>>>>>> Changes", >> >>>>>>>>>>>>>>>>>>>> can >> >>>>>>>>>>>>>>>>>>>>>>>>> we just use catalog api for this >> >>>>>>>>> requirement? >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> Best, >> >>>>>>>>>>>>>>>>>>>>>>>>> Jingsong >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 10:48 AM Jacky >> >>>>>>>> Lau < >> >>>>>>>>>>>>>>>>>>> liuyong...@gmail.com >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ran: >> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for driving the FLIP. the >> >>>>>>> google >> >>>>>>>>> doc >> >>>>>>>>>>>> looks >> >>>>>>>>>>>>>>>> really >> >>>>>>>>>>>>>>>>>>> good. >> >>>>>>>>>>>>>>>>>>>> it >> >>>>>>>>>>>>>>>>>>>>>> is >> >>>>>>>>>>>>>>>>>>>>>>>>>> important to improve user interactive >> >>>>>>>>>>>> experience. >> >>>>>>>>>>>>>> +1 >> >>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>>> support >> >>>>>>>>>>>>>>>>>>>>>> this >> >>>>>>>>>>>>>>>>>>>>>>>>>> feature. >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Jing Ge <j...@ververica.com.invalid> >> >>>>>>>>>>>> 于2023年2月23日周四 >> >>>>>>>>>>>>>>>>>> 00:51写道： >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ran, >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for driving the FLIP. It >> >>>>>>> looks >> >>>>>>>>>>> overall >> >>>>>>>>>>>>>>> good. >> >>>>>>>>>>>>>>>>>> Would >> >>>>>>>>>>>>>>>>>>>> you >> >>>>>>>>>>>>>>>>>>>>>>> like to >> >>>>>>>>>>>>>>>>>>>>>>>>> add >> >>>>>>>>>>>>>>>>>>>>>>>>>>> a description of useLike and >> >>>>>>> notLike? >> >>>>>>>> I >> >>>>>>>>>>> guess >> >>>>>>>>>>>>>>> useLike >> >>>>>>>>>>>>>>>>>> true >> >>>>>>>>>>>>>>>>>>>> is for >> >>>>>>>>>>>>>>>>>>>>>>>>> "LIKE" >> >>>>>>>>>>>>>>>>>>>>>>>>>>> and notLike true is for "NOT LIKE" >> >>>>>>>> but I >> >>>>>>>>>> am >> >>>>>>>>>>>> not >> >>>>>>>>>>>>>>> sure >> >>>>>>>>>>>>>>>>> if I >> >>>>>>>>>>>>>>>>>>>>>>> understood it >> >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly. Furthermore, does it make >> >>>>>>>>> sense >> >>>>>>>>>>> to >> >>>>>>>>>>>>>>> support >> >>>>>>>>>>>>>>>>>>> "ILIKE" >> >>>>>>>>>>>>>>>>>>>>>> too? >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>>>>>>>>>>>>>>> Jing >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 22, 2023 at 1:17 PM Ran >> >>>>>>>> Tao >> >>>>>>>>> < >> >>>>>>>>>>>>>>>>>>>> chucheng...@gmail.com> >> >>>>>>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently flink sql auxiliary >> >>>>>>>>> statements >> >>>>>>>>>>> has >> >>>>>>>>>>>>>>>>> supported >> >>>>>>>>>>>>>>>>>>> some >> >>>>>>>>>>>>>>>>>>>>>> good >> >>>>>>>>>>>>>>>>>>>>>>>>> features >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> such as catalog/databases/table >> >>>>>>>>> support. >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> But these features are not very >> >>>>>>>>> complete >> >>>>>>>>>>>>>> compared >> >>>>>>>>>>>>>>>>> with >> >>>>>>>>>>>>>>>>>>>> other >> >>>>>>>>>>>>>>>>>>>>>>> popular >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> engines such as spark, presto, >> >>>>>>> hive >> >>>>>>>>> and >> >>>>>>>>>>>>>>> commercial >> >>>>>>>>>>>>>>>>>>> engines >> >>>>>>>>>>>>>>>>>>>> such >> >>>>>>>>>>>>>>>>>>>>>>> as >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> snowflake. >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, many engines support >> >>>>>>>> show >> >>>>>>>>>>>>>> operation >> >>>>>>>>>>>>>>>> with >> >>>>>>>>>>>>>>>>>>>> filtering >> >>>>>>>>>>>>>>>>>>>>>>>>> except >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> flink, and support describe other >> >>>>>>>>>>>> object(flink >> >>>>>>>>>>>>>>> only >> >>>>>>>>>>>>>>>>>>> support >> >>>>>>>>>>>>>>>>>>>>>>> describe >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> table). >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wonder can we add these useful >> >>>>>>>>>> features >> >>>>>>>>>>>> for >> >>>>>>>>>>>>>>>> flink? >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> You can find details in this >> >>>>>>> doc.[1] >> >>>>>>>>> or >> >>>>>>>>>>>>>> FLIP.[2] >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, please let me know if there >> >>>>>>>> is a >> >>>>>>>>>>>> mistake. >> >>>>>>>>>>>>>>>>> Looking >> >>>>>>>>>>>>>>>>>>>> forward >> >>>>>>>>>>>>>>>>>>>>>>> to >> >>>>>>>>>>>>>>>>>>>>>>>>> your >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reply. >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [1] >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>> >> >>> >> >> >> https://docs.google.com/document/d/1hAiOfPx14VTBTOlpyxG7FA2mB1k5M31VnKYad2XpJ1I/ >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [2] >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>> >> >>> >> >> >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-297%3A+Improve+Auxiliary+Sql+Statements >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards, >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ran Tao >> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>>> Sergey >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>> Sergey >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Best regards, >> >>>>>>> Sergey >> >>>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> >> -- >> >> Best regards, >> >> Sergey >> >> >> > >> >>
