Hi Chanhae, Thanks for driving this FLIP. The motivation makes sense to me: the current equal-width JDBC partitioning does not work well for skewed data, and it also does not help much when users do not have a suitable numeric/date/timestamp partition column.
I am generally supportive of the direction, but I think both proposed approaches need clearer semantics. For physical-id partitioning, ROWID/ctid are physical identifiers rather than stable logical keys. They may change after updates, table rewrites, vacuum, or row movement. Since different splits may be read by different statements or connections, the FLIP should clarify whether this mode only targets static tables, or whether the connector can provide a consistent snapshot across all splits. Otherwise, missing or duplicated rows may be possible. For boundary-query partitioning, the contract should also be more precise. For example, if scan.partition.num is N, should the query return N - 1 boundaries? How are inclusive/exclusive predicates generated? How should NULL values, duplicate boundaries, unordered results, or boundary count mismatches be handled? These details are important to avoid missing or duplicated rows. It would also be helpful to define the option validation matrix clearly, e.g. which options are required or mutually exclusive for range partitioning, boundary-query partitioning, and physical-id partitioning. Overall, I like the direction, but I think the FLIP should first nail down the correctness guarantees and edge-case behavior. Best, Leonard
