[Simplified Version] Add table redirection support to SPI and Hive's redirection to Iceberg

[lxynov]

Removed DDL, INSERT, COMMENT, ANALYZE, etc. support w.r.t. #5160.

The engine tries to do redirection only for table reads and metadata listing in this PR.

[sopel39]

Curious if you have seen io.trino.spi.connector.ConnectorMetadata#applyTableScanRedirect. Do you think it could be used for your use case?

[lxynov]

Curious if you have seen io.trino.spi.connector.ConnectorMetadata#applyTableScanRedirect. Do you think it could be used for your use case?

@sopel39 ConnectorMetadata#applyTableScanRedirect is expected to return a mapping of source column handles to destination table columns. However, an Iceberg table might not have correct Hive metadata stored in HMS, which is required to generate correct Hive column handles.

[phd3]

Reviewed first 3 commits.

[phd3]

I'm not sure if we want to do this. may be we can keep these features isolated for now.

[phd3]

We're now returning a stream version of List<GrantInfo> which's expected to have additional info on tablename and redirection. So may be naming TableGrantInfo instead of ListTablePrivilegesResult is more appropriate?

or using a stream of Map.Entry<SchemaTableName, Optional<GrantInfo>> might be easier to relate with the current listTablePrivileges method?

[phd3]

the call verifyNoAggregateWindowOrGroupingFunctions should not use table.getName for error message.

visitTable -> analyzeFiltersAndMasks -> analyzeColumnMasks -> verifyNoAggregateWindowOrGroupingFunctions

[phd3]

if redirected view doesn't exist, we don't return the original view here. but in the unfiltered case, we don't check whether redirected view exists, so it appears. This seems to introduce another inconsistency between filtered/unfiltered case, right?

this seems to hint towards having another similar api for listViews, but not sure about a good design for it.

[sopel39]

@sopel39 ConnectorMetadata#applyTableScanRedirect is expected to return a mapping of source column handles to destination table columns. However, an Iceberg table might not have correct Hive metadata stored in HMS, which is required to generate correct Hive column handles.

@lxynov Could you elaborate more? We don't need to generate target Hive column handles when redirecting, but just proper column names. I expect during redirection one knows which source column handle maps to which target column name.

[lxynov]

@sopel39 Sure. This is to handle the case of redirecting from Hive Connector to Iceberg Connector. To use ConnectorMetadata#applyTableScanRedirect, we must have valid source (Hive) column handles, which might not be possible if an Iceberg table doesn't have valid Hive metadata (stored in HMS). Apart from this, ConnectorMetadata#applyTableScanRedirect doesn't have support for metadata listing. But this PR tries to make queries like SELECT * FROM hive.information_schema.columns also return Iceberg table columns.

[phd3]

Superseded by #7606