API: Clarify atomicity requirements for SupportsNamespaces.dropNamespace

[fanruan-tuco]

Query engine

None — custom catalog implementation backed by FoundationDB

Question

I am implementing a FoundationDB-backed catalog and would like to clarify the concurrency contract of SupportsNamespaces.dropNamespace before choosing the implementation semantics.

The current Javadoc says that the method drops a namespace, returns true if it was dropped, and may throw NamespaceNotEmptyException when the namespace is not empty. It does not state whether checking emptiness and deleting the namespace must be atomic with respect to concurrent catalog operations.

For example:

1. dropNamespace(ns) observes no child namespaces, tables, views, or other objects.
2. A concurrent createTable(ns.table) commits successfully.
3. dropNamespace(ns) deletes the namespace and returns true.

Should the API require behavior equivalent to a linearizable conditional delete? In the example above, I would expect either the drop to linearize first and the concurrent create to fail, or the create to linearize first and the drop to fail with NamespaceNotEmptyException. A successful drop should not invalidate or orphan an object that committed before the drop.

Built-in implementations appear to provide different levels of protection:

• InMemoryCatalog checks children, tables, and views under the same monitor.
• Nessie performs a commit and maps a server-side NAMESPACE_NOT_EMPTY conflict.
• Hive and BigQuery delegate restricted deletion to one backend operation.
• JDBC, Glue, DynamoDB, and ECS perform separate list/check and delete operations.
• The REST specification says only that the namespace must be empty.

FoundationDB can perform the emptiness check and namespace deletion in one serializable transaction, and that is the behavior I currently plan to implement. I would like to confirm whether this is required by the API, recommended as a stronger implementation guarantee, or intentionally left implementation-specific.