sql: properly enforce uniqueness of key columns for FK references #43793
Conversation
|
This change is |
thoszhang
force-pushed
the
fix-fk-unique-index-matching
branch
from
ea2e60b
to
15f0b07
Compare
There was a problem hiding this comment.
Minor nit, otherwise LGTM!
Not important for this PR, but checking -- could we also allow these kinds of indices if they were in different order, e.g. can a foreign key referencing (a, b) match on unique index (b, a)?
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @lucy-zhang and @otan)
pkg/sql/sqlbase/table.go, line 426 at r1 (raw file):
// Search for a unique index on the referenced table that matches our foreign // key columns. if len(referencedTable.PrimaryIndex.ColumnIDs) == len(referencedColIDs) &&
nit: I think these changes read better if we had an Equal function defined on the ColumnIDs data type.
|
pkg/sql/sqlbase/table.go, line 426 at r1 (raw file): Previously, otan (Oliver Tan) wrote…
(or "Exactly") |
thoszhang
force-pushed
the
fix-fk-unique-index-matching
branch
2 times, most recently
from
4906f5d
to
609a554
Compare
There was a problem hiding this comment.
Reviewable status:
pkg/sql/sqlbase/table.go, line 426 at r1 (raw file):
Previously, otan (Oliver Tan) wrote…
(or "Exactly")
Done.
There was a problem hiding this comment.
We don't support that yet, but I think there are indefinite plans to support it eventually.
Reviewable status:
We introduced a bug in 19.2 that would allow, e.g., a unique index on `(a, b, c)` to be used as an index that is supposed to enforce uniqueness for a foreign key constraint pointing only to `(a, b)`. This PR reintroduces a check that the indexed columns match the FK columns exactly. Release note (bug fix): Fixed a bug introduced in 19.2 that would allow foreign keys to use a unique index on the referenced columns that indexed more columns than were included in the columns used in the FK constraint, which allows potentially violating uniqueness in the referenced columns themselves.
thoszhang
force-pushed
the
fix-fk-unique-index-matching
branch
from
609a554
to
6430e47
Compare
|
TFTR! bors r+ |
43311: colserde: add simple serialization for DECIMALs r=yuzefovich a=yuzefovich This commit adds simple serialization of DECIMALs using the provided MarshalText method. Touches: #37044. Release note (sql change): Previously, DECIMALs could not be sent over the network when the computation was performed by the vectorized engine. This has been fixed, and the vectorized engine now fully supports DECIMAL type. 43793: sql: properly enforce uniqueness of key columns for FK references r=lucy-zhang a=lucy-zhang We introduced a bug in 19.2 that would allow, e.g., a unique index on `(a, b, c)` to be used as an index that is supposed to enforce uniqueness for a foreign key constraint pointing only to `(a, b)`. This PR reintroduces a check that the indexed columns match the FK columns exactly. Fixes #42680. Release note (bug fix): Fixed a bug introduced in 19.2 that would allow foreign keys to use a unique index on the referenced columns that indexed more columns than were included in the columns used in the FK constraint, which allows potentially violating uniqueness in the referenced columns themselves. 43956: build: post issues from local roachtests r=andreimatei a=tbg This wasn't happening due to some missing env vars. I noticed this since there are many failures of acceptance/version-upgrade not reflected via created issues (I get email notifications from TC). Release note: None Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com> Co-authored-by: Lucy Zhang <lucy-zhang@users.noreply.github.com> Co-authored-by: Tobias Schottdorf <tobias.schottdorf@gmail.com>
|
The TC failure seems to be this test flake: #43826 |
Build succeeded |
We introduced a bug in 19.2 that would allow, e.g., a unique index on
(a, b, c)to be used as an index that is supposed to enforce uniqueness for a foreignkey constraint pointing only to
(a, b). This PR reintroduces a check that theindexed columns match the FK columns exactly.
Fixes #42680.
Release note (bug fix): Fixed a bug introduced in 19.2 that would allow foreign
keys to use a unique index on the referenced columns that indexed more columns
than were included in the columns used in the FK constraint, which allows
potentially violating uniqueness in the referenced columns themselves.