Currently the kv write path does not recheck that a replicating row abides by the destination table's CHECK constraints. That being said, since LDR only supports single column family tables & tables with identical schema, then the replicating row already passed the identical check on the source side. So, it really isn't a big deal to skip replicating check constraints on the kv write path. There are 2 reasons we want to continue to conduct check constraints on the kv write path though:
There are a few edge cases where an expression can evaluate in an on-deterministic fashion (think 1/0+null), which could cause a check constraint to pass on the source but not on the destination. If the kv writer does write a row that fails the check constraint, it could later crash SQL query executions or cause incorrect ie non-repeatable query results.
we eventually want the sql and kv write paths to converge.
Currently the kv write path does not recheck that a replicating row abides by the destination table's CHECK constraints. That being said, since LDR only supports single column family tables & tables with identical schema, then the replicating row already passed the identical check on the source side. So, it really isn't a big deal to skip replicating check constraints on the kv write path. There are 2 reasons we want to continue to conduct check constraints on the kv write path though:
Jira issue: CRDB-44144