Don't warn about foreign keys causing table scan when creating table in same transaction

[andrewsmith]

I started to put this together to address an extension of #220: the case where the table is created and a foreign key constraint is added in the same transaction. We use a tool that generates SQL from a language-specific mapper and it separates these into two steps:

-- instead of 
CREATE TABLE foo (
  user_id BIGINT REFERENCES users (id),
  ...
);

-- or
CREATE TABLE foo (
  user_id BIGINT,
  ...
  CONSTRAINT user_id_fk FOREIGN KEY user_id REFERENCES users (id)
);

-- it generates
CREATE TABLE foo (
  user_id BIGINT,
  ...
);
ALTER TABLE foo ADD CONSTRAINT user_id_fk FOREIGN KEY user_id REFERENCES users (id);

In this case, there should be no table scan or it should be near instantaneous. I put together this change to adapt this rule to recognize this, but there are some shortcomings.

If someone were to have INSERT or COPY statements between the table creation and the foreign key addition, then the table scan becomes a real risk again. It also seems fairly intractable to determine this, as INSERT/COPY statements could be hidden in a stored procedure or function that is executed between the CREATE TABLE and ALTER TABLE commands.

Anyhow, I wanted to put this up for consideration and see if you had any thoughts on that problem. I imagine the INSERT/COPY between creation and foreign key addition would be pretty unlikely, but would cause Squawk to produce a false-negative, which is unsettling.

[netlify]

👷 Deploy request for squawkhq pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	ba7d66e