David Phillips

Thanks!

The last time I looked, the Parquet crypto classes rely on Hadoop `Configuration`. Also, they’re mixed together in a JAR with other Hadoop-requiring classes, so we don’t include `parquet-hadoop` in...

Sorry for the confusion. I was answering these comments: > many classes in the crypto package are identical to the same classes in the Apache parquet-java artifact. Can we re-use...

I don't think we want to simply replace each properties file with TOML. Rather, we'd like to have a single TOML file for everything, so that server config, catalogs, access...

I think we should remove this wording from the exchange manager documentation. It's very unlikely vendor documentation will tell the user about compatibility with Trino.

The user needs to test it themselves and contact the vendor with any questions.

I’m not aware of anyone working on it, but contributions are welcome. A good first step would be to describe how this works, from a technical perspective.

Can we add an integration test that shows this property is used by the HMS as intended?

Geospatial is basically built-in (including engine support for spatial joins), so I think it should be in the default package.

This is loading classes dynamically based on class names in config. We should use the standard Trino pattern of having explicitly enumerated providers, each with their own strongly typed config...