Hi all,
Thanks for all of your response.
If there's no more comments, I would like to bring up the VOTE.
Best,
Wei
> 在 2020年3月13日，20:50，Xingbo Huang 写道：
>
> Hi Wei,
> Thanks a lot for drafting the FLIP and kicking off the discussion.
> Big +1 for this feature.
> This feature will greatly faci
Hi Wei,
Thanks a lot for drafting the FLIP and kicking off the discussion.
Big +1 for this feature.
This feature will greatly facilitate PyFlink users to use Python UDF in SQL
scenarios.
Best,
Xingbo
Hequn Cheng 于2020年3月13日周五 下午5:10写道：
> Big +1 on this feature! It would be great to extend the u
Big +1 on this feature! It would be great to extend the usage of Python UDF
in SQL scenarios.
The design doc looks good from my side now. Thank you for the update.
Best,
Hequn
On Tue, Mar 10, 2020 at 3:50 PM Wei Zhong wrote:
> Hi Timo,
>
> Thanks for your reply.
>
> If we aim for the option 1,
Hi Timo,
Thanks for your reply.
If we aim for the option 1, it makes sense for me to include the change in this
FLIP as the option 1 does not change any public API. I'll update the FLIP page
to illustrate this.
Best,
Wei
> 在 2020年3月9日，17:58，Timo Walther 写道：
>
> Hi Wei,
>
> I agree with Daw
Hi Wei,
I agree with Dawid that we should defer the instantiation of temporary
functions to compile time. In the long-term, we would like to integrate
FunctionCatalog as a component of CatalogManager and unify the handling
of catalog objects as much as possible.
We should aim for your propos
Hi Dawid,
I think defering the instantiation of temporary functions to compile time is
quite a good idea but needs further discussion. As it is orthogonal with this
FLIP, we could continue the discussion in a new thread later. What do you think?
Best,
Wei
> 在 2020年3月5日，21:11，Wei Zhong 写道：
>
Hi Dawid,
Thanks for your suggestion.
After some investigation, there are two designs in my mind about how to defer
the instantiation of temporary system function and temporary catalog function
to compile time.
1. FunctionCatalog accepts both FunctionDefinitions and uninstantiated
temporary
Hi all,
I had a really quick look and from my perspective the proposal looks fine.
I share Jarks opinion that the instantiation could be done at a later
stage. I agree with Wei it requires some changes in the internal
implementation of the FunctionCatalog, to store temporary functions as
catalog fu
Thanks for the explanation, Wei!
On Mon, 2 Mar 2020 at 20:59, Wei Zhong wrote:
> Hi Jark,
>
> Thanks for your suggestion.
>
> Actually, the timing of starting a Python process depends on the UDF type,
> because the Python process is used to provide the necessary information to
> instantiate the
Hi Jark,
Thanks for your suggestion.
Actually, the timing of starting a Python process depends on the UDF type,
because the Python process is used to provide the necessary information to
instantiate the FunctionDefinition object of the Python UDF. For catalog
function, the FunctionDefinition
Hi Weizhong,
Thanks for proposing this feature. In geneal, I'm +1 from the table's view.
I have one suggestion: I think the register python function into catalog
doesn't need to startup python process (the "High Level Sequence Diagram"
in your FLIP).
Because only meta-information is persisted int
Big +1 for this feature.
We built our SQL platform on Java Table API, and most common UDF are
implemented in Java. However some python developers are not familiar with
Java/Scala, and it's very inconvenient for these users to use UDF in SQL.
Wei Zhong 于2020年2月28日周五 下午6:58写道：
> Thank for your re
Thank for your reply Dan!
By the way, this FLIP is closely related to the SQL API. @Jark Wu
@Timo could you please take a look?
Thanks,
Wei
> 在 2020年2月25日，16:25，zoudan 写道：
>
> +1 for supporting Python UDF in Java/Scala Table API.
> This is a great feature and would be helpful for python us
+1 for supporting Python UDF in Java/Scala Table API.
This is a great feature and would be helpful for python users!
Best,
Dan Zou
14 matches
Mail list logo
