-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Introduce getSqlInvokedFunctions
SPI and BuiltInPluginFunctionNamespaceManager
for registering sql invoked functions
#25597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
getSqlFunctions
SPI and BuiltInPluginFunctionNamespaceManager
for registering sql invoked functions
getSqlFunctions
SPI and BuiltInPluginFunctionNamespaceManager
for registering sql invoked functionsgetSqlInvokedFunctions
SPI and BuiltInPluginFunctionNamespaceManager
for registering sql invoked functions
9132721
to
343f6e3
Compare
...-base/src/main/java/com/facebook/presto/metadata/BuiltInTypeAndFunctionNamespaceManager.java
Outdated
Show resolved
Hide resolved
presto-main-base/src/main/java/com/facebook/presto/metadata/BuiltInFunctionHandle.java
Outdated
Show resolved
Hide resolved
6b2e35c
to
6977df3
Compare
6977df3
to
8825888
Compare
@rschlussel @tdcmeehan Can you please have a look? |
Hi Pratik. I have some questions:
|
presto-main-base/src/main/java/com/facebook/presto/metadata/FunctionAndTypeManager.java
Show resolved
Hide resolved
@kevintang2022 I am writing a RFC for this SPI change. I hope that'll answer all the questions, but if not I can come back and clarify here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering why BuiltInPluginFunctionNamespaceManager
doesn't actually extend from a FunctionNamespaceManager
? Also if we changed it so it was a namespace manager, could we use a subclass of FunctionHandle
to indicate it's a built-in.
@tdcmeehan I did not extend it from |
// Could still match to a magic literal function | ||
if (e.getErrorCode().getCode() != StandardErrorCode.FUNCTION_NOT_FOUND.toErrorCode().getCode()) { | ||
throw e; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why will this happen? I assume this PR should not change the existing behavior, i.e. an AA change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean this change in particular?
// Could still match to a magic literal function
if (e.getErrorCode().getCode() != StandardErrorCode.FUNCTION_NOT_FOUND.toErrorCode().getCode()) {
throw e;
}
getMatchingFunctionHandle
could return exceptions now, just catching a specific exception, if the exception is because no matching function was found, we continue searching as it could still match to a magic literal function. It still matches what the current behavior is just an additional try catch block.
@@ -834,7 +849,6 @@ private Optional<FunctionNamespaceManager<? extends SqlFunction>> getServingFunc | |||
} | |||
|
|||
@Override | |||
@SuppressWarnings("unchecked") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why removing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Collection<SqlFunction> candidates = (Collection<SqlFunction>) functionNamespaceManager.get().getFunctions(Optional.empty(), functionName);
We removed this cast hence that is no longer needed.
@@ -61,12 +68,12 @@ public static List<? extends SqlFunction> extractFunctions(Class<?> clazz) | |||
} | |||
|
|||
if (clazz.isAnnotationPresent(SqlInvokedScalarFunction.class)) { | |||
return SqlInvokedScalarFromAnnotationsParser.parseFunctionDefinition(clazz); | |||
return SqlInvokedScalarFromAnnotationsParser.parseFunctionDefinition(clazz, defaultNamespace); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that SqlInvokedScalarFunction will all be under the defaultNamespace? There are other function plugins which return SqlInvokedFunctions, for example MySqlFunctionNamespaceManager, RestBasedFunctionNamespaceManager, JsonFileBasedFunctionNamespaceManager, will this be a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we accept the fully qualified name while registering functions under those namespaces.
In this change, I am just adding a parameter to indicate what the default namespace is. If it went down this code path earlier without my change, we were extracting and registering those functions under presto.default
.
return Stream.concat(Stream.of(functionHeader.value()), stream(functionHeader.alias()))
.map(name -> new SqlInvokedFunction(
QualifiedObjectName.valueOf(JAVA_BUILTIN_NAMESPACE, name),
parameters,
typeVariableConstraints,
emptyList(),
Now we just pass in the default namespace param instead of registering it under JAVA_BUILTIN_NAMESPACE (presto.default
) always.
@@ -62,13 +63,13 @@ public FunctionListBuilder scalars(Class<?> clazz) | |||
|
|||
public FunctionListBuilder sqlInvokedScalar(Class<?> clazz) | |||
{ | |||
functions.addAll(SqlInvokedScalarFromAnnotationsParser.parseFunctionDefinition(clazz)); | |||
functions.addAll(SqlInvokedScalarFromAnnotationsParser.parseFunctionDefinition(clazz, JAVA_BUILTIN_NAMESPACE)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar questions as above
8825888
to
6c9bea4
Compare
6c9bea4
to
021fb1c
Compare
Summary: This PR includes changes for Built in functions for different use cases - Register SQL invoked function in built in namespace when they come from plugins (prestodb#25597) - Register Native functions in built in namespace when they come from sidecar (prestodb/rfcs#41) Since these use cases have a lot of overlap, we can introduce an abstract class in order to reduce duplicate logic. ## Description ## Motivation and Context ## Impact Pull Request resolved: prestodb#25661 Test Plan: <!---Please fill in how you tested your change--> ## Contributor checklist - [ ] Please make sure your submission complies with our [contributing guide](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md), in particular [code style](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#code-style) and [commit standards](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#commit-standards). - [ ] PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced. - [ ] Documented new properties (with its default value), SQL syntax, functions, or other functionality. - [ ] If release notes are required, they follow the [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines). - [ ] Adequate tests were added if applicable. - [ ] CI passed. ## Release Notes Please follow [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines) and fill in the release notes below. ``` == RELEASE NOTES == General Changes * ... * ... Hive Connector Changes * ... * ... ``` If release note is NOT required, use: ``` == NO RELEASE NOTE == ``` Rollback Plan: Differential Revision: D79301760 Pulled By: kevintang2022
Summary: This PR includes changes for Built in functions for different use cases - Register SQL invoked function in built in namespace when they come from plugins (prestodb#25597) - Register Native functions in built in namespace when they come from sidecar (prestodb/rfcs#41) Since these use cases have a lot of overlap, we can introduce an abstract class in order to reduce duplicate logic. ## Description ## Motivation and Context ## Impact Pull Request resolved: prestodb#25661 Test Plan: <!---Please fill in how you tested your change--> ## Contributor checklist - [ ] Please make sure your submission complies with our [contributing guide](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md), in particular [code style](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#code-style) and [commit standards](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#commit-standards). - [ ] PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced. - [ ] Documented new properties (with its default value), SQL syntax, functions, or other functionality. - [ ] If release notes are required, they follow the [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines). - [ ] Adequate tests were added if applicable. - [ ] CI passed. ## Release Notes Please follow [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines) and fill in the release notes below. ``` == RELEASE NOTES == General Changes * ... * ... Hive Connector Changes * ... * ... ``` If release note is NOT required, use: ``` == NO RELEASE NOTE == ``` Rollback Plan: Differential Revision: D79301760 Pulled By: kevintang2022
presto-main-base/src/main/java/com/facebook/presto/metadata/BuiltInFunctionHandle.java
Outdated
Show resolved
Hide resolved
presto-spi/src/main/java/com/facebook/presto/spi/function/FunctionHandle.java
Outdated
Show resolved
Hide resolved
Summary: This PR includes changes for Built in functions for different use cases - Register SQL invoked function in built in namespace when they come from plugins (prestodb#25597) - Register Native functions in built in namespace when they come from sidecar (prestodb/rfcs#41) Since these use cases have a lot of overlap, we can introduce an abstract class in order to reduce duplicate logic. ## Description ## Motivation and Context ## Impact Pull Request resolved: prestodb#25661 Test Plan: <!---Please fill in how you tested your change--> ## Contributor checklist - [ ] Please make sure your submission complies with our [contributing guide](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md), in particular [code style](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#code-style) and [commit standards](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#commit-standards). - [ ] PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced. - [ ] Documented new properties (with its default value), SQL syntax, functions, or other functionality. - [ ] If release notes are required, they follow the [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines). - [ ] Adequate tests were added if applicable. - [ ] CI passed. ## Release Notes Please follow [release notes guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines) and fill in the release notes below. ``` == RELEASE NOTES == General Changes * ... * ... Hive Connector Changes * ... * ... ``` If release note is NOT required, use: ``` == NO RELEASE NOTE == ``` Rollback Plan: Differential Revision: D79301760 Pulled By: kevintang2022
da0f19e
to
8d9aa5a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some nits
presto-main-base/src/main/java/com/facebook/presto/metadata/FunctionMap.java
Show resolved
Hide resolved
presto-spi/src/main/java/com/facebook/presto/spi/function/BuiltInFunctionKind.java
Outdated
Show resolved
Hide resolved
bd0669b
…ceManager for registering sql invoked functions
Co-Authored-by: Naveen Mahadevuni <[email protected]>
bd0669b
to
230a997
Compare
Thanks for the release note! Minor format nits:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work!
Description
Introduces a new
getSqlInvokedFunctions
SPI in Presto, which only supports SQL invoked functions. This SPI enables plugins to register SQL invoked functions via a new built-in plugin function namespace manager interface:BuiltInPluginFunctionNamespaceManager
.Motivation and Context
This change is motivated by the need to safely support SQL invoked functions that may overlap with native C++ functions
pulled from the sidecar. By registering inlined SQL invoked functions through a dedicated SPI and validating them against the functions residing in the default function namespace manager, we ensure clear separate and prevent conflicts in function resolution.
Impact
No impact for now, but after this change the inlined SQL invoked functions would no longer be registered as built in functions under the
BuiltInTypeAndFunctionNamespaceManager
but instead be provided via a plugin.Test Plan
CI and Unit tests
Contributor checklist
Release Notes
Please follow release notes guidelines and fill in the release notes below.