I think one of the challenges is that current DDL only supports defining clustering/partitioning on table creation, but doesn't support altering them afterwards. So I'm not sure if overriding Index class would work, or we should add a new class such as Clustering and Partitioning instead.

Current API allows modifying clustering settings in-place, but not for partitioning.

Also there are several constraints compared to regular relational DB indexing:

• At most one clusterings/partitioning is allowed per table
• Only top-level columns and specific data types are supported
  • Clustering does not allow sorting on derived column (e.g.: result from applying some function on a column, or sum of two numerical columns)
  • In most cases, partitioning relies on derived column to specify binning (e.g.: Truncated result given specified precision on (date)time values; Applying RANGE_BUCKET on integers)
• Clustering has limit on number of columns for assigning multi-column sorting (maximum 4 columns for now)
• Can only specify one column for partitioning
• Optional filtering requirement on partitioned column, which also means type checking (or runtime?) should fail on query statements without specifying filtering condition against these columns

Thanks @chalmerlowe !!!

Thank @nlenepveu
They did all the heavy lifting.