Do you think we should also show the non-identity partition transform?

@hantangwangd I think that's a valid ask. What would you suggest we should mention in the Extra info in this case? Should we mention the transformation being used for the hidden partitioning for the respective columns?

@imjalpreet For non-identity partition column, I think show the transform information would be enough, maybe something like partition by '<transform.toString()>'. So that it would be shown as follows:

presto:default> desc test_table;
 Column |   Type    |           Extra            | Comment 
--------+-----------+----------------------------+---------
 a      | integer   | partition key              |         
 b      | varchar   | partition by 'truncate[2]' |         
 c      | timestamp | partition by 'year'        |         
(3 rows)

presto:default> show columns in test_table;
 Column |   Type    |           Extra            | Comment 
--------+-----------+----------------------------+---------
 a      | integer   | partition key              |         
 b      | varchar   | partition by 'truncate[2]' |         
 c      | timestamp | partition by 'year'        |         
(3 rows)

Is that ok? Or do you have a better idea?

@hantangwangd let's say for a date/timestamp column we have two hidden partition transforms year and month. What would be the best way to display that? Should we write partition by year, month or is there a better way to communicate that there are two hidden partition transforms on this column?

@imjalpreet Thanks for providing this great question, so that we can discuss and handle it. Yes, Iceberg allows create multiple transforms on a column. After a careful check in the spec and the implementation, I found the follow details:

1. Multiple transforms on the same column has a explicit sequence, and Iceberg use the same sequence to organize the partitioned data files.
2. Year/Month/Day/Hour belong to the same kind of transform, so that they can not be created on the same column.
3. The column types that could be applied with Year/Month/Day/Hour is disjoint with the columns types that could be applied with Truncate.

So we can get some conclusions:

1. Transforms after Identity transform is somewhat meaningless, as they would always get the same value, so maybe we should disallow it explicitly?
2. The most complex definition is something like ARRAY['truncate(a, 2)', 'bucket(a, 16)', 'a'] or ARRAY['year(b)', 'bucket(b, 16)', 'b'], including three different kind of transforms.

So do you think the following shown examples is reasonable?

partition key			//This is the most common scenario
partition by year
partition by hour
partition by month, identity
partition by truncate(2)
partition by truncate(2), bucket(16)
partition by bucket(16)
partition by bucket(16), month
partition by truncate(2), bucket(16), identity
partition by year, bucket(16), identity
......