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 >
