songLee wrote:
>>>>
>>>> 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, Jingsong
gt;>>
>>> Best,
>>>
>>> Dawid
>>> On 23/07/2019 11:40, JingsongLee wrote:
>>>
>>> And I think we should recommend user to use catalog api to
>>> createTable and createFunction,(I guess most scenarios do
>>> not use temporary object
y objects) in this way, it is good to option #3
>>
>> Best, JingsongLee
>>
>>
>> ----------
>> From:JingsongLee > <mailto:lzljs3620...@aliyun.com.INVALID>> > <mailto:lzljs3620...@aliy
I guess most scenarios do
> not use temporary objects) in this way, it is good to option #3
>
> Best, JingsongLee
>
>
> --------------------------
> From:JingsongLee
>
> Send Time:2019年7月23日(星期二) 17:35
> To:dev
> Su
st, JingsongLee
>
>
> --
> From:JingsongLee
> Send Time:2019年7月23日(星期二) 17:35
> To:dev
> Subject: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.
>
>
:2019年7月23日(星期二) 17:35
To:dev
Subject: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
To:dev
Subject: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
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
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
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
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
Hi all,
When working on FLINK-13279[1] we realized we could benefit from a
better temporary objects support in the Catalog API/Table API.
Unfortunately we are already long past the feature freeze that's why I
wanted to get some opinions from the community how should we proceed
with this topic. I
12 matches
Mail list logo
