Re: [DISCUSS] Support temporary tables in SQL API

Thanks for pushing the discussion, Dawid! I’m also fine with option #3. Aljoscha > On 24. Jul 2019, at 12:04, Dawid Wysakowicz wrote: > > Hi all, > > Thank you Xuefu for clarifying your opinion. Now we have 3 votes for both of > the options. To conclude this discussion I am willing to change

Re: [DISCUSS] Support temporary tables in SQL API

Hi all, Thank you Xuefu for clarifying your opinion. Now we have 3 votes for both of the options. To conclude this discussion I am willing to change my vote to option 3 as I had only a slight preference towards option 2. Therefore the final results of the poll are as follows: /option #2: 2 votes

Re: [DISCUSS] Support temporary tables in SQL API

Isn’t https://issues.apache.org/jira/browse/FLINK-13279 already a sign that there are surprises for users if we go with option #3? Aljoscha > On 24. Jul 2019, at 00:33, Xuefu Z wrote: > > I favored #3 if that wasn't obvious. > > Usability i

Re: [DISCUSS] Support temporary tables in SQL API

I favored #3 if that wasn't obvious. Usability issue with #2 makes Hive too hard to use. #3 keeps the old behavior for existing users who don't have Hive and thus there is only one, in-memory catalog. If a user does register Hive, he/she understands that there are multiple catalogs and that fully

Re: [DISCUSS] Support temporary tables in SQL API

I think we all agree so far that we should implement one of the short term solutions for 1.9 release (#2 or #3) and continue the discussion on option #1 for the next release. Personally I prefer option #2, because it is closest to the current behavior and as Kurt said it is the most intuitive one,

Re: [DISCUSS] Support temporary tables in SQL API

And I think we should recommend user to use catalog api to createTable and createFunction,(I guess most scenarios do not use temporary objects) in this way, it is good to option #3 Best, JingsongLee -- From:JingsongLee Send Time:

Re: [DISCUSS] Support temporary tables in SQL API

Thanks Dawid and other people. +1 for using option #3 for 1.9.0 and go with option #1 in 1.10.0. Regarding Xuefu's concern, I don't know how necessary it is for each catalog to deal with tmpView. I think Catalog is different from DB, we can have single concept for tmpView, that make user easier

Re: [DISCUSS] Support temporary tables in SQL API

Thanks Dawid for driving this discussion. Personally, I would +1 for using option #2 for 1.9.0 and go with option #1 in 1.10.0. Regarding Xuefu's concern about option #1, I think we could also try to reuse the in-memory catalog for the builtin temporary table storage. Regarding to option #2 and o

Re: [DISCUSS] Support temporary tables in SQL API

I would be fine with option 3) but I think option 2) is the more implicit solution that has less surprising behaviour. Aljoscha > On 22. Jul 2019, at 23:59, Xuefu Zhang wrote: > > Thanks to Dawid for initiating the discussion. Overall, I agree with Timo > that for 1.9 we should have some quick

Re: [DISCUSS] Support temporary tables in SQL API

Thanks to Dawid for initiating the discussion. Overall, I agree with Timo that for 1.9 we should have some quick and simple solution, leaving time for more thorough discussions for 1.10. In particular, I'm not fully with solution #1. For one thing, it seems proposing storing all temporary objects

Re: [DISCUSS] Support temporary tables in SQL API

Thanks for summarizing our offline discussion Dawid! Even though I would prefer solution 1 instead of releasing half-baked features, I also understand that the Table API should not further block the next release. Therefore, I would be fine with solution 3 but introduce the new user-facing `crea