tison
cc @kokosing I think I've sent the CLA already but the test still failed. Did I miss something here?
@ebyhr two weeks passed. May I have an estimate about your team's reviewing?
When I working on https://github.com/apache/pulsar/pull/16683, I notice that after Trino supports parametric timestamp, the decode case should be review in another round. Related to: * https://github.com/trinodb/trino/commit/21e3ddf55a641e1c17b7e4a17689223ff1120b42 * https://github.com/trinodb/trino/commit/19811d3d58e908d145639b1975ec111a0002e138
ping @ebyhr @Praveen2112 @hashhar
@hashhar I don't get your point. This patch follow the Avro spec and adapt to Trino internal representation design. Trino's `TimestampType` always store the payload in `epochMicros` precision.
And yes, it breaks downstream adoption as in https://github.com/apache/pulsar/pull/16683/commits/c4183950c60ab1648ec94ff0703944fb59c734d7. This is introduced by how we implement parametric timestamp type https://github.com/trinodb/trino/commit/21e3ddf55a641e1c17b7e4a17689223ff1120b42, and out of the scope of this patch.
@hashhar You can read this commit https://github.com/trinodb/trino/pull/13070/commits/52f4cf28912f5e2d5e4933464a0a6a39a04e1bfa that I revert trino-kafka adapting Avro logical type. Still I don't know what changes you proposed here. It follows Avro spec, schema factory...
ping @ebyhr @hashhar @Praveen2112
@Praveen2112 thanks for your reivews! Updated and squashed.
Closed as stale. There're many changes since this patch was made in the first place. Feel free to resubmit it if it's still relevant.