cockroachdb / cockroachdb/cockroach

sql,keys,encoding: use a different key pretty-printer for exclusive upper bound keys

Open
#110,501 0 comments 0 reactions 0 assignees View on GitHub
A-sql-encoding C-bug quality-friday T-sql-foundations
Dominant language
Go
Stars
32.5k
Forks
4.1k
PR merge metrics
PR metrics pending

Description

Found with @ecwall while writing up the separate issues #110491 and #110487.

**Describe the problem**

Currently we apply the same function (`catalogkeys.PrettyKey`, `(roachpb.Key).String{,WithDirs}`, `roachpb.PrettyPrintKey`, `roachpb.SafeFormatKey`) to both the start and end keys of key spans.

This causes two separate problems:

- a **correctness** problem: in many cases, the *end* key of a key span does not contain valid encoded values (because it was generated via `.PrefixEnd()`). The pretty-printer is currently complex and brittle because it tries hard to correct errors related to this.
- a **UX** problem: in most cases, we want to express the end key *in relationship to the start key*. For example, if a span is for a SQL table we want to see `/Table/100` ... `/Table/100/Max` in the pretty-printed output, not `/Table/100.../Table/101`.

**Expected behavior**

We generally want to interpret **exclusive end keys** of spans using separate logic from start keys.

There are two aspects to this:
- there should be two functions that work on individual keys, instead of just one.
- the function that works on exclusive end keys should also accept a corresponding start key as argument, and do extra work to try and *represent* the end key *in relationship to the start key*. For example something like `if endKey == startKey.PrefixEnd() { return startKey.String() + "/Max" }`.

Jira issue: CRDB-31464

Epic CRDB-60948

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.