Currently we use SupportsProjectionPushDown to push down physical columns, and SupportsReadingMetadata is used to read metadata columns. There is no problem when implementing one of the interfaces alone. If two interfaces are implemented at the same time, there will be confusing semantics.
For example, if we update the schema or producedDataType in SupportsProjectionPushDown#applyProjection and SupportsReadingMetadata#applyReadableMetadata at the same time, the former is actually invalid, because the former is called first, and then the latter will overwrite it. There are some similar usage notes in the interface's documentation. But this is very confusing. In this case, you only need to implement SupportsReadingMetadata#applyReadableMetadata (only implement SupportsProjectionPushDown, the override method is empty), and the rule match logic of SupportsReadingMetadata will push down the physical column and metadata columns to generate producedDataType and return it. At this point SupportsProjectionPushDown is more like a marker interface. In addition, if some member variables are relied on in the implementation of SupportsReadingMetadata, and the member variables are also updated in SupportsProjectionPushDown, unexpected problems may occur. Developers should clearly read the implementation of these two interfaces and understand that these overlapping functions will cause a certain development cost to the developer of the connector (normally, the two interfaces should be isolated functions, developers see the meaning of the name ). I wonder if the community has considered making the responsibilities of these two interfaces more independent and clear in subsequent updates. Maybe my understanding is not very sufficient, looking forward to your opinions. -- Best Regards, Ran Tao https://github.com/chucheng92