pvary commented on code in PR #5120:
URL: https://github.com/apache/iceberg/pull/5120#discussion_r925351473
##########
flink/v1.15/flink/src/main/java/org/apache/iceberg/flink/FlinkCatalog.java:
##########
@@ -619,12 +631,17 @@ public void alterPartition(ObjectPath tablePath,
CatalogPartitionSpec partitionS
@Override
public List<String> listFunctions(String dbName) throws CatalogException {
- return Collections.emptyList();
+ return Lists.newArrayList(partitionFunctions.keySet());
}
@Override
public CatalogFunction getFunction(ObjectPath functionPath) throws
FunctionNotExistException, CatalogException {
- throw new FunctionNotExistException(getName(), functionPath);
+ CatalogFunction catalogFunction =
partitionFunctions.get(functionPath.getObjectName());
Review Comment:
Reading the doc linked below:
https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/dev/table/functions/overview/,
I think I understand it now.
Basically we are registering temporary catalog functions, so the queries
will use it anyway, and will not clash with other implementations already
registered on the catalog. What happens if the user already registered a
`bucket` temporary catalog function?
Why do we use catalog functions instead of system functions? I think the
highest priority is the temporary system function, so if we use them we can be
reasonably sure that we do not call any user define functions by mistake.
Another issue I see is that if we already has a function registered with the
same name, then it might be surprising for the user that the implementation is
changed for iceberg tables (not the old catalog level implementation is used,
but the one registered by the Iceberg code). Using a more specific name
(`iceberg_bucket`), like the one suggested by @kbendick would help to reduce
the likelihood of name clashes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
