Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding-foreign-key-constraint shouldn't warn about foreign keys when creating table #220

Open
cdignam-segment opened this issue Jun 22, 2022 · 1 comment

Comments

@cdignam-segment
Copy link
Contributor

I think Squawk shouldn't complain here because there won't be any rows in our table so the lock will be short.

stdin:1:0: warning: adding-foreign-key-constraint

   1 | CREATE TABLE IF NOT EXISTS my.table
   2 | (
   3 |     username                text            primary key,
   4 |     nickname  text            not null,
   5 |     --
   6 |     --
   7 |     --
   8 |     --
   9 |     --
  10 | 
  11 |     CONSTRAINT nickname_fkey
  12 |         FOREIGN KEY (nickname) REFERENCES some.nickname_table (id)
  13 | );

  note: Requires a table scan of the table you're altering and a SHARE ROW EXCLUSIVE lock on both tables, which blocks writes to both tables while your table is scanned.
  help: Add NOT VALID to the constraint in one transaction and then VALIDATE the constraint in a separate transaction.

find detailed examples and solutions for each rule at https://squawkhq.com/docs/rules     
andrewsmith added a commit to andrewsmith/squawk that referenced this issue Mar 3, 2023
This addresses sbdchd#220, which claims that although an exclusive lock will
be obtained on the referenced table, there are no rows in the
referencing table so the table scan under the exclusive lock should be
short or non-existent.
@maximus1108
Copy link

maximus1108 commented May 10, 2023

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants