Currently, it is difficult to write an inline value that would also include an MVCCValueHeader. In fact, a caller of the KV APIs would have to go substantially out of their way to produce such a value.
As we include more features that require reading MVCCValueHeader values, it would be nice if we could be sure that inline values do not need to be handled in such cases.
Towards this end, we should:
Add a test-only assertion in the inline write path that values aren't using the extended encoding.
Add a test-only assertion in the read path that we don't encounter extended encoding. It's unclear to me whether we'll need changes to the kvnemesis code to do this.
Describe the problem
Currently, it is difficult to write an inline value that would also include an MVCCValueHeader. In fact, a caller of the KV APIs would have to go substantially out of their way to produce such a value.
As we include more features that require reading MVCCValueHeader values, it would be nice if we could be sure that inline values do not need to be handled in such cases.
Towards this end, we should:
Jira issue: CRDB-42648