[MCOL-3693] Table CHECK constraint pretends to work but breaks transactional properties Created: 2019-12-25 Updated: 2020-11-09 Resolved: 2020-11-09 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | N/A |
| Affects Version/s: | 1.4.2 |
| Fix Version/s: | 5.5.1 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Todd Stoffel (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | Compatibility | ||
| Issue Links: |
|
||||||||
| Epic Link: | ColumnStore Compatibility Improvements | ||||||||
| Description |
|
CREATE TABLE above works without any errors or warnings.
Following SELECT expectedly returns an empty result set:
Next INSERT doesn't break the constraint, so it works.
|
| Comments |
| Comment by Andrew Hutchings (Inactive) [ 2019-12-26 ] |
|
Almost certain this hasn't been implemented for non-MariaDB bulk insert methods and I'm surprised the DDL even parses. |
| Comment by Elena Stepanova [ 2019-12-26 ] |
|
I would say the main problem here is not that the DDL passes, and not that the check doesn't work, but that it seemingly works at first, and the table is empty after the failed check, but after the second INSERT previously rejected values get pulled out from nowhere. |
| Comment by Roman [ 2020-09-30 ] |
|
This is a questionable thing b/c the syntax support simplifies table creation. However I agree that a warning should be made that the CHECK constraint feature works only partially. |