The committers are authorized under a signed CLA.

• ✅ JiajunBernoulli (765515995c9fa5319a30e9ac3f0e47bb35566feb)

I'm a bit confused. How does this work with the normal namespace (or schema) that we use for tables, views etc.? We should not mix the namespace concept with backend. Also, it's relatively uncommon I would think for someone to switch db for these metadata entities. So it will help if you can elaborate the use-case better.

I'm a bit confused. How does this work with the normal namespace (or schema) that we use for tables, views etc.? We should not mix the namespace concept with backend. Also, it's relatively uncommon I would think for someone to switch db for these metadata entities. So it will help if you can elaborate the use-case better.

First, this will not affect the normal table and view. This is a traditional namespace concept, not only for tables, but also for functions. We need namespace to manage different functions, so it does not mix the namespace concept with backend.

Second, it's low frequency operation within a single company. But for presto user who on the cloud, they all need different namespaces to distinguish their own functions.

I'm a bit confused. How does this work with the normal namespace (or schema) that we use for tables, views etc.? We should not mix the namespace concept with backend. Also, it's relatively uncommon I would think for someone to switch db for these metadata entities. So it will help if you can elaborate the use-case better.

First, this will not affect the normal table and view. This is a traditional namespace concept, not only for tables, but also for functions. We need namespace to manage different functions, so it does not mix the namespace concept with backend.

Function namespace is not a SQL concept. That's why it's confusing. Why can't you just use the normal namespace? In SQL, all entities live in a schema which is where all ACL etc are applied. SO I'm thinking if we can just use that instead of adding a new concept.

Second, it's low frequency operation within a single company. But for presto user who on the cloud, they all need different namespaces to distinguish their own functions.

Same should hold for tables/views as well?

I'm a bit confused. How does this work with the normal namespace (or schema) that we use for tables, views etc.? We should not mix the namespace concept with backend. Also, it's relatively uncommon I would think for someone to switch db for these metadata entities. So it will help if you can elaborate the use-case better.

First, this will not affect the normal table and view. This is a traditional namespace concept, not only for tables, but also for functions. We need namespace to manage different functions, so it does not mix the namespace concept with backend.

Function namespace is not a SQL concept. That's why it's confusing. Why can't you just use the normal namespace? In SQL, all entities live in a schema which is where all ACL etc are applied. SO I'm thinking if we can just use that instead of adding a new concept.

Second, it's low frequency operation within a single company. But for presto user who on the cloud, they all need different namespaces to distinguish their own functions.

Same should hold for tables/views as well?

You are right, I renamed namespace to schema.

Actually I'm saying don't create a separate schema just for functions. Use the existing schema concept and also not sure why you need create/drop - I'm not sure if we have good framework to support proper deletion without creating garbage and orphaned entities (lack of cascade). For tables it's generally fine but for functions this could be confusing.

At a high level, I still think this is a backend metastore implementation concept that does not need a syntax.

In fact, it is more confusing for presto users to use other databases to implement it. Users should not care about the details of the backend, just use our syntax.
Once again: on the public cloud, presto user and presto admin is different roles. If users want to add a function schema, they must contact the administrator.

So if this is for admins? The description is not clear. If you can give a hypothetical use case, that will help a lot.

You know Faas, a presto cluster of cloud vendors may be used by different users(Those users can only use Presto for calculation, not mysql)
Different users need different function namespaces, It is convenient for users to use presto syntax. Otherwise, presto cluster administrator on the cloud need to execute many different insert into ....
In short, my purpose is to reduce the burden of presto administrators and improve the user experience of presto users

This pull request has been automatically marked as stale because it has not had recent activity. If you'd still like this PR merged, please comment on the task, make sure you've addressed reviewer comments, and rebase on the latest master. Thank you for your contributions!