cockroachdb / cockroachdb/cockroach
sql: drop and add constraint with same name in one statement
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
The following problem exists in legacy schema changer:
Setup:
```
CREATE TABLE t (i INT PRIMARY KEY);
ALTER TABLE t ADD CONSTRAINT check_i CHECK (i > 0);
```
Troubled Stmt:
```
ALTER TABLE t DROP CONSTRAINT check_i, ADD CONSTRAINT check_i CHECK (i > 0), VALIDATE CONSTRAINT check_i;
```
(The first easy-to-fix error is the ADD CONSTRAINT will complain that the name "check_i" is already used. This is easily fixed by adding some logic in `alter_table.go:validateConstraintNameIsNotUsed`)
After that, it still errors with the `VALIDATE CONSTRAINT` clause saying "constraint check_i does not exist". The root cause is that we deduplicated when we build the constraint cache so that `catalog.FindConstraintByName` in VALIDATE CONSTRAINT will see the dropping constraint check_i, and fail to realize there is another adding constraint (with the same name).
I don't have an idea on how to fix it elegantly, and it's probably not worth it since this can be beautifully handled in the declarative schema changer, but I still open this issue for tracking.
Jira issue: CRDB-24354
Epic CRDB-60946
Contributor guide
Research direction
Reproduce the SQL statements in the issue, then inspect alter_table.go, especially validateConstraintNameIsNotUsed, and follow catalog.FindConstraintByName during VALIDATE CONSTRAINT handling. The fix should allow a constraint to be dropped and re-added with the same name in one statement, with validation resolving the newly added constraint.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, sql
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100