constraint pages #901
constraint pages #901
Conversation
sploiselle
force-pushed
the
constraint-pages
branch
from
42b6658
to
0db0c0e
Compare
| - Binary encoding is now supported in the network protocol for `BOOL`, `FLOAT`, `DECIMAL`, and `STRING` types, improving compatiblity with some PostgreSQL drivers. [#6661](https://github.com/cockroachdb/cockroach/pull/6661) | ||
| - The new `cockroach freeze-cluster` [command](cockroach-commands.html) has been added to the command-line interface; it will be used in the upgrade process for a future beta release. [#6675](https://github.com/cockroachdb/cockroach/pull/6675) | ||
|
|
||
| ### Bug Fixes | ||
|
|
||
| - [`EXPLAIN DELETE`](explain.html) no longer executes the `DELETE` statement. [#6622](https://github.com/cockroachdb/cockroach/pull/6622) | ||
| - [`CHECK`](constraints.html#check) constraints are now enforced during [`UPDATE`](update.html) statments. [#6753](https://github.com/cockroachdb/cockroach/pull/6753) | ||
| - [`CHECK`](constraints.html#check) constraints now work correctly when columns have been dropped. [#6730](https://github.com/cockroachdb/cockroach/pull/6730) | ||
| - [`CHECK`](check.html) constraints are now enforced during [`UPDATE`](update.html) statments. [#6753](https://github.com/cockroachdb/cockroach/pull/6753) |
There was a problem hiding this comment.
Spelling error in the original: statments
|
|
||
| - Check constraints requires that the column values satisfy a Boolean expression within the constraint. The expression must evaluate to `TRUE` (or *NULL*) for every row affected by an `INSERT` or `UPDATE` statement. The DML statement will fail if the condition evaluates to `FALSE` for any row. | ||
| - Check constraints may be specified at the column or table level and can reference other columns within the table. Internally, all column level Check constrints are converted to table level constraints so they can be handled in a consistent fashion. | ||
| - You can have multiple Check constraints on a single column but ideally these should be combined using the logical operators. So, for example, |
There was a problem hiding this comment.
I like this recommendation, but is there a technical reason behind it? Or is this just best practice in terms of legibility?
There was a problem hiding this comment.
Tested this and it's actually getting converted to two inequalities. So, not sure. @bdarnell Any suggestions as to why we make this recommendation?
There was a problem hiding this comment.
OK, that makes sense. Whenever a "should"-type recommendation is used, as a reader, I prefer a little of the reasoning. How about:
... but ideally, for computational efficiency, they should be combined using the logical operators.
There was a problem hiding this comment.
it'll be slightly cheaper to evaluate fewer expressions, and we can potentially optimize things away, etc so yeah, when it doesn't make it harder to understand/maintain, folding multiple CHECK expressions into one is good, but the savings aren't usually going to be a big deal.
| warranty_period INT CHECK (warranty_period BETWEEN 0 AND 24) | ||
| ~~~ | ||
|
|
||
| - Check constraints that refer to multiple columns should be specified at the [table level](#multiple-column-table-level). |
There was a problem hiding this comment.
Seems reasonable, but is there a technical reason behind this recommendation?
There was a problem hiding this comment.
This was in the existing doc, but I'm not sure about the technical reasoning. @bdarnell can you provide a rationale for this recommendation apart from legibility in the CREATE TABLE statement?
There was a problem hiding this comment.
Right, sorry to loop that edit in here. We could handle that in a separate PR, if you like.
There was a problem hiding this comment.
All CHECK constraints get moved to the table level anyway, so it doesn't really matter.
| @@ -6,287 +6,22 @@ toc: false | |||
|
|
|||
| Constraints offer additional data integrity by enforcing conditions on the data within a column or row. They are checked during DML operations and restrict the data values within a column to those specified within the constraint. | |||
|
|
|||
| If a constraint refers to only one column (column-level constraint) it can be defined against the column as part of its definition. If a constraint refers to more than one column (table-level constraint) it needs to be defined as a separate entry in the tables definition. | |||
| If a constraint refers to only one column (column-level constraint) it can be defined against the column as part of its definition. If a constraint refers to more than one column (table-level constraint) it needs to be defined as a separate entry in the tables definition. | |||
There was a problem hiding this comment.
nit: In both sentences, add a comma after the closing parenthesis to separate the clauses.
sploiselle
force-pushed
the
constraint-pages
branch
from
0db0c0e
to
cdab97d
Compare
sploiselle
force-pushed
the
constraint-pages
branch
from
cdab97d
to
e2555cc
Compare
Converted
constraints.mdas a branch page to individual pages for each constraint:check.mddefault-value.mdforeign-key.mdnot-null.mdprimary-key.mdunique.mdAlso updated all links and changed sidebar structure to surface Constraints as third-level items.
This change is