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

Is require-concurrent-index-creation necessary straight after table creation? #349

Open
maciej opened this issue May 24, 2024 · 2 comments

Comments

@maciej
Copy link

maciej commented May 24, 2024

Currently if even if an index is created directly after the table it refers to require-concurrent-index-creation will be triggered. Index creation on an empty table is virtually instantaneous and locking a table that is unlikely to receive writes until the migration script finishes seems like a non-issue to me.

Example migrate script:

create table if not exists customer
(
    email text
);

create unique index if not exists idx_custome_email on customer (email);

squawk output:

> squawk up.sql
up.sql:5:2: warning: require-concurrent-index-creation

   5 | create unique index if not exists idx_custome_email on customer (email);

  note: Creating an index blocks writes.
  help: Create the index CONCURRENTLY.

find detailed examples and solutions for each rule at https://squawkhq.com/docs/rules

I'd suggest relaxing the rule in cases where tables and their indexes are created in the same file.

@sbdchd
Copy link
Owner

sbdchd commented May 24, 2024

Yeah if the table has just been created it won't matter since there's no data

@chdsbd
Copy link
Collaborator

chdsbd commented May 25, 2024

If you wrap your migration in a transaction squawk won't warn:

begin;
create table if not exists customer
(
    email text
);

create unique index if not exists idx_custome_email on customer (email);
commit;

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

No branches or pull requests

3 participants