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 > > > > > >
