Hey Martijn,

Thanks for the feedback and the opinions!

In terms of your questions:

- Yes, the new syntax will support multiple artifacts, similar to JAR. This was 
an oversight in the syntax in the flip, thanks for pointing it out!
- I think mixing would be permissible at this stage, if we wish to scope this 
behaviour in future (by, say, limiting ARTIFACT to only non-Java functions) we 
would have to revisit it. Unless it makes sense at this point to prevent mixing 
in anticipation of this?
- Yes, it should. I’ll update the FLIP with this.

Thank you for the feedback!

Kind regards,
Mika

> On 19. Jan 2026, at 10:08, Mika Naylor <[email protected]> wrote:
> 
> Hey Martijn,
> 
> Thanks for the feedback and the opinions!
> 
> In terms of your questions:
> 
> - Yes, the new syntax will support multiple artifacts, similar to JAR. This 
> was an oversight in the syntax in the flip, thanks for pointing it out!
> - I think mixing would be permissible at this stage, if we wish to scope this 
> behaviour in future (by, say, limiting ARTIFACT to only non-Java functions) 
> we would have to revisit it. Unless it makes sense at this point to prevent 
> mixing in anticipation of this?
> - Yes, it should. I’ll update the FLIP with this.
> 
> Thank you for the feedback!
> 
> Kind regards,
> Mika
> 
>> On 2026/01/14 09:45:36 Martijn Visser wrote:
>> Hi Mika,
>> 
>> Thanks for the FLIP and apologies for not replying earlier. I've reviewed
>> it and overall I think this is a good proposal that addresses a need for
>> future-proofing the CREATE FUNCTION syntax. The alignment with the Table
>> API's generic ResourceUri approach is well-reasoned, and the backward
>> compatibility story is clean.
>> 
>> I have one question on the syntax when it comes to multiple artifacts.
>> 
>> The current Flink documentation shows that CREATE FUNCTION supports
>> multiple JARs:
>> USING JAR '<path_to_filename>.jar' [, JAR '<path_to_filename>.jar']*
>> 
>> However, the proposed syntax in the FLIP only shows a single artifact:
>> [USING JAR|ARTIFACT 'artifact_path']
>> 
>> Could you clarify:
>> - Will the new syntax support multiple artifacts like `USING ARTIFACT
>> 'a.jar', ARTIFACT 'b.jar'`?
>> - Can we mix keywords within a single statement, e.g., `USING JAR 'a.jar',
>> ARTIFACT 'b.jar'`?
>> - Should the grammar be updated to: `[USING (JAR|ARTIFACT) 'artifact_path'
>> [, (JAR|ARTIFACT) 'artifact_path']* ]`?
>> 
>> Best regards,
>> 
>> Martijn
>> 
>> On Thu, Dec 4, 2025 at 8:50 PM Zander Matheson <[email protected]>
>> wrote:
>> 
>>> Thanks for creating the FLIP! This is a great move to continue to evolve
>>> our SQL syntax to include future developments on the language front as well
>>> as different types of artifacts like models.
>>> 
>>>> On Thu, Dec 4, 2025 at 9:39 AM Mika Naylor <[email protected]> wrote:
>>> 
>>>> Hey everyone,
>>>> 
>>>> I would like to kick off a discussion on FLIP-559: Add ARTIFACT keyword
>>>> option in CREATE FUNCTION's USING clause [1].
>>>> 
>>>> The current syntax for registering a user-defined function that depends
>>> on
>>>> a binary artifact requires using the JAR keyword within the CREATE
>>>> FUNCTION’s USING clause. As Flink's ecosystem evolves, particularly with
>>>> improved Python support (e.g., Python UDFs depending on wheel files or
>>>> other archives), the JAR keyword becomes semantically incorrect and
>>>> restrictive. We would like to add a more generic way to specify a
>>>> dependency artifact by adding an ARTIFACT keyword that functions the same
>>>> as JAR, but feels more format agnostic to the user.
>>>> 
>>>> For more details, please refer to the FLIP [1]. There was also a previous
>>>> pre-FLIP discussion thread [2].
>>>> 
>>>> Would love any feedback and thoughts the community might have on this!
>>>> 
>>>> Kind regards,
>>>> Mika Naylor
>>>> 
>>>> [1]
>>>> 
>>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-559%3A+Add+ARTIFACT+keyword+option+in+CREATE+FUNCTION%27s+USING+clause
>>>> [2] https://lists.apache.org/thread/3hthbgrho598pr7ycsoygk8mqv84cmzt
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to