Test GitHub comment demo

[ienugr]

GitHub Comment Testing Summary

Successful Tests:

• Normal comment generation (6 violations)
• SQL truncation (33 violations)
• Multiple files handling
• Error handling for oversized content

Large File Tests:

• File: 60,000+ lines
• Violations: 30,003 issues
• Comment size: 1,165,116 characters (18x over limit)
• Error caught: 'Comment body is too large'

Analysis:

• The fix is working for normal use cases
• Error handling prevents GitHub API failures
• Summary mode logic may need adjustment for extreme cases

[netlify]

👷 Deploy request for squawkhq pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	852bcb2

[ienugr]

Squawk Report

🚒 6 violations across 1 file(s)

---

migrations/001_demo_normal_comment.sql

-- Demo Migration 001: Normal GitHub Comment Generation
-- This migration demonstrates typical violations that should generate
-- a normal GitHub comment with full SQL content

BEGIN;

-- Adding NOT NULL field without default (violation)
ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;

-- Adding foreign key constraint (violation)  
ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
    FOREIGN KEY (user_id) REFERENCES users(id);

-- Changing column type (violation)
ALTER TABLE products ALTER COLUMN price TYPE decimal(10,2);

-- Adding field with default value (violation)
ALTER TABLE users ADD COLUMN status integer DEFAULT 1;

COMMIT;

🚒 Rule Violations (6)

warning[adding-required-field]: Adding a new column that is `NOT NULL` and has no default value to an existing table effectively makes it required.
 --> migrations/001_demo_normal_comment.sql:8:19
  |
8 | ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;
  |                   --------------------------------------
  |
  = help: Make the field nullable or add a non-VOLATILE DEFAULT
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
 --> migrations/001_demo_normal_comment.sql:8:36
  |
8 | ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;
  |                                    ------------
  |
  = help: Use a `TEXT` field with a `CHECK` constraint.
warning[constraint-missing-not-valid]: By default new constraints require a table scan and block writes to the table while that scan occurs.
  --> migrations/001_demo_normal_comment.sql:11:19
   |
11 |   ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
   |  ___________________-
12 | |     FOREIGN KEY (user_id) REFERENCES users(id);
   | |______________________________________________-
   |
   = help: Use `NOT VALID` with a later `VALIDATE CONSTRAINT` call.
warning[adding-foreign-key-constraint]: Adding a foreign key constraint requires a table scan and a `SHARE ROW EXCLUSIVE` lock on both tables, which blocks writes to each table.
  --> migrations/001_demo_normal_comment.sql:11:23
   |
11 |   ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
   |  _______________________-
12 | |     FOREIGN KEY (user_id) REFERENCES users(id);
   | |______________________________________________-
   |
   = help: Add `NOT VALID` to the constraint in one transaction and then VALIDATE the constraint in a separate transaction.
warning[changing-column-type]: Changing a column type requires an `ACCESS EXCLUSIVE` lock on the table which blocks reads and writes while the table is rewritten. Changing the type of the column may also break other clients reading from the table.
  --> migrations/001_demo_normal_comment.sql:15:41
   |
15 | ALTER TABLE products ALTER COLUMN price TYPE decimal(10,2);
   |                                         ------------------
   |
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/001_demo_normal_comment.sql:18:37
   |
18 | ALTER TABLE users ADD COLUMN status integer DEFAULT 1;
   |                                     -------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.

---

📚 More info on rules

⚡️ Powered by Squawk (2.21.1), a linter for PostgreSQL, focused on migrations

[ienugr]

Squawk Report

🚒 33 violations across 1 file(s)

---

migrations/002_demo_sql_truncation.sql

-- Demo Migration 002: SQL Truncation Test
-- This migration has 60+ lines to test the SQL truncation feature
-- Expected: SQL content truncated at 50 lines with truncation notice

BEGIN;

-- Adding NOT NULL field (violation at the beginning)
ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;

-- Generate enough content to trigger truncation
CREATE TABLE demo_table_1 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_2 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_3 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_4 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_5 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_6 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP

-- ... (17 more lines truncated for brevity)

⚠️ Note: SQL content has been truncated for display purposes. The full analysis was performed on the complete file.

🚒 Rule Violations (33)

warning[adding-required-field]: Adding a new column that is `NOT NULL` and has no default value to an existing table effectively makes it required.
 --> migrations/002_demo_sql_truncation.sql:8:19
  |
8 | ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;
  |                   -------------------------------------
  |
  = help: Make the field nullable or add a non-VOLATILE DEFAULT
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
 --> migrations/002_demo_sql_truncation.sql:8:36
  |
8 | ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;
  |                                    -----------
  |
  = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:12:8
   |
12 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:12:8
   |
12 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:13:10
   |
13 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:14:16
   |
14 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:15:16
   |
15 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:19:8
   |
19 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:19:8
   |
19 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:20:10
   |
20 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:21:16
   |
21 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:22:16
   |
22 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:26:8
   |
26 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:26:8
   |
26 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:27:10
   |
27 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:28:16
   |
28 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:29:16
   |
29 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:33:8
   |
33 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:33:8
   |
33 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:34:10
   |
34 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:35:16
   |
35 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:36:16
   |
36 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:40:8
   |
40 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:40:8
   |
40 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:41:10
   |
41 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:42:16
   |
42 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:43:16
   |
43 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:47:8
   |
47 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:47:8
   |
47 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:48:10
   |
48 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:49:16
   |
49 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:50:16
   |
50 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[changing-column-type]: Changing a column type requires an `ACCESS EXCLUSIVE` lock on the table which blocks reads and writes while the table is rewritten. Changing the type of the column may also break other clients reading from the table.
  --> migrations/002_demo_sql_truncation.sql:65:47
   |
65 | ALTER TABLE products ALTER COLUMN description TYPE text;
   |                                               ---------
   |

---

📚 More info on rules

⚡️ Powered by Squawk (2.21.1), a linter for PostgreSQL, focused on migrations

[ienugr]

Squawk Report

🚒 39 violations across 2 file(s)

---

migrations/001_demo_normal_comment.sql

-- Demo Migration 001: Normal GitHub Comment Generation
-- This migration demonstrates typical violations that should generate
-- a normal GitHub comment with full SQL content

BEGIN;

-- Adding NOT NULL field without default (violation)
ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;

-- Adding foreign key constraint (violation)  
ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
    FOREIGN KEY (user_id) REFERENCES users(id);

-- Changing column type (violation)
ALTER TABLE products ALTER COLUMN price TYPE decimal(10,2);

-- Adding field with default value (violation)
ALTER TABLE users ADD COLUMN status integer DEFAULT 1;

COMMIT;

🚒 Rule Violations (6)

warning[adding-required-field]: Adding a new column that is `NOT NULL` and has no default value to an existing table effectively makes it required.
 --> migrations/001_demo_normal_comment.sql:8:19
  |
8 | ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;
  |                   --------------------------------------
  |
  = help: Make the field nullable or add a non-VOLATILE DEFAULT
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
 --> migrations/001_demo_normal_comment.sql:8:36
  |
8 | ALTER TABLE users ADD COLUMN email varchar(255) NOT NULL;
  |                                    ------------
  |
  = help: Use a `TEXT` field with a `CHECK` constraint.
warning[constraint-missing-not-valid]: By default new constraints require a table scan and block writes to the table while that scan occurs.
  --> migrations/001_demo_normal_comment.sql:11:19
   |
11 |   ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
   |  ___________________-
12 | |     FOREIGN KEY (user_id) REFERENCES users(id);
   | |______________________________________________-
   |
   = help: Use `NOT VALID` with a later `VALIDATE CONSTRAINT` call.
warning[adding-foreign-key-constraint]: Adding a foreign key constraint requires a table scan and a `SHARE ROW EXCLUSIVE` lock on both tables, which blocks writes to each table.
  --> migrations/001_demo_normal_comment.sql:11:23
   |
11 |   ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id 
   |  _______________________-
12 | |     FOREIGN KEY (user_id) REFERENCES users(id);
   | |______________________________________________-
   |
   = help: Add `NOT VALID` to the constraint in one transaction and then VALIDATE the constraint in a separate transaction.
warning[changing-column-type]: Changing a column type requires an `ACCESS EXCLUSIVE` lock on the table which blocks reads and writes while the table is rewritten. Changing the type of the column may also break other clients reading from the table.
  --> migrations/001_demo_normal_comment.sql:15:41
   |
15 | ALTER TABLE products ALTER COLUMN price TYPE decimal(10,2);
   |                                         ------------------
   |
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/001_demo_normal_comment.sql:18:37
   |
18 | ALTER TABLE users ADD COLUMN status integer DEFAULT 1;
   |                                     -------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.

---

migrations/002_demo_sql_truncation.sql

-- Demo Migration 002: SQL Truncation Test
-- This migration has 60+ lines to test the SQL truncation feature
-- Expected: SQL content truncated at 50 lines with truncation notice

BEGIN;

-- Adding NOT NULL field (violation at the beginning)
ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;

-- Generate enough content to trigger truncation
CREATE TABLE demo_table_1 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_2 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_3 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_4 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_5 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

CREATE TABLE demo_table_6 (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP

-- ... (17 more lines truncated for brevity)

⚠️ Note: SQL content has been truncated for display purposes. The full analysis was performed on the complete file.

🚒 Rule Violations (33)

warning[adding-required-field]: Adding a new column that is `NOT NULL` and has no default value to an existing table effectively makes it required.
 --> migrations/002_demo_sql_truncation.sql:8:19
  |
8 | ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;
  |                   -------------------------------------
  |
  = help: Make the field nullable or add a non-VOLATILE DEFAULT
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
 --> migrations/002_demo_sql_truncation.sql:8:36
  |
8 | ALTER TABLE users ADD COLUMN phone varchar(20) NOT NULL;
  |                                    -----------
  |
  = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:12:8
   |
12 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:12:8
   |
12 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:13:10
   |
13 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:14:16
   |
14 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:15:16
   |
15 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:19:8
   |
19 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:19:8
   |
19 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:20:10
   |
20 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:21:16
   |
21 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:22:16
   |
22 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:26:8
   |
26 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:26:8
   |
26 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:27:10
   |
27 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:28:16
   |
28 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:29:16
   |
29 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:33:8
   |
33 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:33:8
   |
33 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:34:10
   |
34 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:35:16
   |
35 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:36:16
   |
36 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:40:8
   |
40 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:40:8
   |
40 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:41:10
   |
41 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:42:16
   |
42 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:43:16
   |
43 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-bigint-over-int]: Using 32-bit integer fields can result in hitting the max `int` limit.
  --> migrations/002_demo_sql_truncation.sql:47:8
   |
47 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use 64-bit integer values instead to prevent hitting this limit.
warning[prefer-identity]: Serial types make schema, dependency, and permission management difficult.
  --> migrations/002_demo_sql_truncation.sql:47:8
   |
47 |     id SERIAL PRIMARY KEY,
   |        ------
   |
   = help: Use an `IDENTITY` column instead.
warning[prefer-text-field]: Changing the size of a `varchar` field requires an `ACCESS EXCLUSIVE` lock, that will prevent all reads and writes to the table.
  --> migrations/002_demo_sql_truncation.sql:48:10
   |
48 |     name VARCHAR(100),
   |          ------------
   |
   = help: Use a `TEXT` field with a `CHECK` constraint.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:49:16
   |
49 |     created_at TIMESTAMP DEFAULT NOW(),
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[prefer-timestamp-tz]: When Postgres stores a datetime in a `timestamp` field, Postgres drops the UTC offset. This means 2019-10-11 21:11:24+02 and 2019-10-11 21:11:24-06 will both be stored as 2019-10-11 21:11:24 in the database, even though they are eight hours apart in time.
  --> migrations/002_demo_sql_truncation.sql:50:16
   |
50 |     updated_at TIMESTAMP
   |                ---------
   |
   = help: Use timestamptz instead of timestamp for your column type.
warning[changing-column-type]: Changing a column type requires an `ACCESS EXCLUSIVE` lock on the table which blocks reads and writes while the table is rewritten. Changing the type of the column may also break other clients reading from the table.
  --> migrations/002_demo_sql_truncation.sql:65:47
   |
65 | ALTER TABLE products ALTER COLUMN description TYPE text;
   |                                               ---------
   |

---

📚 More info on rules

⚡️ Powered by Squawk (2.21.1), a linter for PostgreSQL, focused on migrations

[ienugr]

GitHub Comment Testing Summary

Successful Tests:

• Normal comment generation (6 violations)
• SQL truncation (33 violations)
• Multiple files handling
• Error handling for oversized content

Large File Tests:

• File: 60,000+ lines
• Violations: 30,003 issues
• Comment size: 1,165,116 characters (18x over limit)
• Error caught: 'Comment body is too large'

Analysis:

• The fix is working for normal use cases
• Error handling prevents GitHub API failures
• Summary mode logic may need adjustment for extreme cases