You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
createtableif not exists customer
(
email text
);
createunique indexif 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.
The text was updated successfully, but these errors were encountered:
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:
squawk output:
I'd suggest relaxing the rule in cases where tables and their indexes are created in the same file.
The text was updated successfully, but these errors were encountered: