Unimplemented errors occur when CRDB recognizes a SQL feature but it is not yet supported. These unimplemented errors can be used by the product team to help prioritize the roadmap. These errors are also useful to customers when they provide links to Github issues which detail the problem as well as potential workarounds. However, to this point, CRDB does not always effectively distinguish SQL entry errors from unimplemented features and does not reliably link unimplemented feature errors to Github issues. The fact a feature is not implemented pops us as follows in CockroachDB:
The feature requires syntax that CRDB does not recognize at all. This causes a parse error indistinguishable from a mistake client-side.
The feature requires syntax that CRDB recognizes but immediately reports with an error clearly marked as "unimplemented feature." Some of these are already linked to a Github issue, some are tagged with a textual label aimed to surface in reported usage metrics, and some are not linked to any label/issue visible to PM.
This document focuses on increasing the ability of PM to track unimplemented features as well as increase the information available to customers attempting to use unimplemented features.
...
For many reasons, CRDB may choose to not include the entirety of a SQL feature within a given release. Recent examples include CTEs or Timetz. Each time a feature is implemented partially, or an engineer is aware that there may be user demand for more than what is being implemented, the error reported should include:
At the very least, a marker that the feature is unsupported with a tracking label.
As much as possible, a link to a GitHub issue where the user can discover an explanation and possible workarounds.
The engineer implementing the feature should create GitHub issues as needed.
The Github issue should be labeled with "docs-todo" and "known-limitation."
Add the label X-anchored-telemetry if the issue is referenced from the product (see below), so as to prevent closure due to inactivity.
The marker that a feature is unimplemented should be placed with pgerror.UnimplementedWithIssue() (preferred) or pgerror.Unimplemented() (otherwise), so it can be recognized as an unimplemented feature error by the tracking logic that sends these messages to the reporting server (currently via (sql.Server).recordError or (*Executor).RecordError).
...