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
