Thanks for the proposal. The proposed getRawMessage solution would be a breaking change for existing TableView API users since it would unnecessarily consume more memory and CPU. That's why a different approach should be taken. I've suggested resolving the issue by adding new methods to the API for returning a TableView with Message as the type parameter:
TableView<Message<T>> createForMessages() throws PulsarClientException; CompletableFuture<TableView<Message<T>>> createForMessagesAsync() throws PulsarClientException; Would this approach solve your use case? -Lari On 2025/10/14 07:51:59 List wrote: > Hi Pulsar Devs, > > I would like to start a discussion for a new proposal, PIP-444: Expose Raw > Message Access in TableView API. > > The motivation for this PIP is to allow users of the TableView API to > access the full message metadata (e.g., properties, event time), not just > the deserialized value. This will improve the utility of TableView for a > wider range of use cases. > > The full proposal document is available for review and comments in the > following Pull Request: https://github.com/apache/pulsar/pull/24842 > > The implementation for this proposal is being developed in PR #24809. > Looking forward to your feedback. > > Thanks, > namest504 >
