Description

PostgresQueryRunner now alters type/length via ALTER COLUMN ... TYPE ... USING, but it does not
drop/recreate an existing DEFAULT, which can make ALTER TYPE fail when the default can’t be cast.
TypeORM already drops DEFAULT for enum type changes to avoid casting issues, so the new generic path
is inconsistent and may introduce migration failures for columns with defaults.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1578-1596]

+                const newFullType = this.driver.createFullType(newColumn)
+                const oldFullType = this.driver.createFullType(oldColumn)
               upQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                        }" TYPE ${newFullType} USING "${
+                            newColumn.name
+                        }"::${newFullType}`,
                   ),
               )
               downQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                        }" TYPE ${oldFullType} USING "${
+                            newColumn.name
+                        }"::${oldFullType}`,
                   ),

Evidence

The new generic type/length/precision/scale change path adds a USING cast but does not touch column
defaults, so any existing DEFAULT remains in place during ALTER TYPE. In the same method, enum type
changes explicitly drop DEFAULT to avoid type-casting issues, and the generic default-update logic
only runs when the default expression changes—meaning type-only changes won’t adjust defaults at
all.

src/driver/postgres/PostgresQueryRunner.ts[1569-1597]
src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
src/driver/postgres/PostgresQueryRunner.ts[2218-2223]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PostgresQueryRunner.changeColumn` now uses `ALTER COLUMN ... TYPE ... USING` for type/length changes, but it leaves existing `DEFAULT` expressions in place. PostgreSQL can fail `ALTER COLUMN TYPE` when a column has a default that cannot be cast to the new type. TypeORM already mitigates this in the enum-type-change flow by dropping the default before the type change.
### Issue Context
- The new generic type/length/precision/scale change block adds a USING cast but does not drop/recreate defaults.
- Default updates later in the method only run when `newColumn.default !== oldColumn.default`, so type-only changes won’t re-apply defaults if we drop them.
- `executeMemoryDownSql()` runs `downQueries.reverse()`, so order of `downQueries.push(...)` matters.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1569-1598]
- src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
- src/driver/postgres/PostgresQueryRunner.ts[2218-2270]
### Implementation notes
- In the generic type-change block, if either old/new column has a default:
- set `defaultValueChanged = true`
- add an `upQueries` step to `DROP DEFAULT` **before** the `ALTER COLUMN ... TYPE ... USING` query
- add an `upQueries` step to `SET DEFAULT <newColumn.default>` (or keep dropped if new default is null/undefined) **after** the type change
- add corresponding `downQueries` that restore the old default (or drop it if old had none)
- Ensure you don’t double-apply defaults via the later default-update section (the `defaultValueChanged` flag should prevent that).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

PostgresQueryRunner.changeColumn now builds ALTER COLUMN TYPE statements from
PostgresDriver.createFullType(). For enum/simple-enum columns, createFullType() does not translate
to the underlying user-defined enum type name (it just uses column.type), so changing a column
to/from enum can generate invalid SQL like TYPE enum / ::enum, and non-enum→enum conversions also
won’t create the enum type.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1578-1623]

+                const newFullType = this.driver.createFullType(newColumn)
+                const oldFullType = this.driver.createFullType(oldColumn)
+
+                // if column has a default, drop it before ALTER TYPE to avoid
+                // casting failures (same pattern used for enum type changes)
+                if (
+                    oldColumn.default !== null &&
+                    oldColumn.default !== undefined
+                ) {
+                    defaultValueChanged = true
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ALTER COLUMN "${oldColumn.name}" DROP DEFAULT`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ALTER COLUMN "${
+                                oldColumn.name
+                            }" SET DEFAULT ${oldColumn.default}`,
+                        ),
+                    )
+                }
+
               upQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                        }" TYPE ${newFullType} USING "${
+                            newColumn.name
+                        }"::${newFullType}`,
                   ),
               )
               downQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                        }" TYPE ${oldFullType} USING "${
+                            newColumn.name
+                        }"::${oldFullType}`,
                   ),
               )

Evidence

The new type-change path in changeColumn uses PostgresDriver.createFullType() for both the TYPE
clause and the USING cast. PostgresDriver.createFullType() simply returns the TableColumn.type with
length/precision adjustments and has no enum/simple-enum special-casing, while
PostgresQueryRunner.buildCreateColumnSql explicitly handles enum/simple-enum by using
buildEnumName(table, column). Additionally, enum type creation exists in addColumn, but
changeColumn’s enum-handling block only runs when both old and new are already enum/simple-enum
(enum value/name changes), not for non-enum→enum conversions.

src/driver/postgres/PostgresQueryRunner.ts[1569-1647]
src/driver/postgres/PostgresDriver.ts[1269-1330]
src/driver/postgres/PostgresQueryRunner.ts[5031-5061]
src/driver/postgres/PostgresQueryRunner.ts[1031-1037]
src/driver/postgres/PostgresQueryRunner.ts[1649-1656]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PostgresQueryRunner.changeColumn` now uses `this.driver.createFullType()` for `ALTER COLUMN ... TYPE` and its `USING` cast. For `enum`/`simple-enum`, `PostgresDriver.createFullType()` does **not** return the underlying user-defined enum type name (it uses `column.type`), which can produce invalid SQL (`TYPE enum`, `::enum`). Additionally, non-enum → enum conversions don’t create the enum type.
### Issue Context
Postgres enum columns are emitted via `buildEnumName(...)` in `buildCreateColumnSql`, and enum types are created in `addColumn` via `hasEnumType/createEnumTypeSql`. The new ALTER TYPE path should match that behavior.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1569-1647]
- src/driver/postgres/PostgresQueryRunner.ts[5031-5061]
- src/driver/postgres/PostgresQueryRunner.ts[1020-1037]
- src/driver/postgres/PostgresDriver.ts[1269-1330]
### Expected change (high level)
- Introduce a small local helper inside `changeColumn` to compute `newTypeSql` / `oldTypeSql`:
- if enum/simple-enum: use `this.buildEnumName(table, col)` (+ `[]` if array)
- else: use `this.driver.createFullType(col)
- If converting non-enum → enum/simple-enum:
- ensure enum type exists (`hasEnumType` / `createEnumTypeSql`) before the ALTER TYPE
- consider a safer `USING` expression (possibly `"col"::text::enum_type`) similar to existing enum-change logic.
- Use these computed type SQL strings in both up/down ALTER TYPE queries.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

PostgresQueryRunner now alters type/length via ALTER COLUMN ... TYPE ... USING, but it does not
drop/recreate an existing DEFAULT, which can make ALTER TYPE fail when the default can’t be cast.
TypeORM already drops DEFAULT for enum type changes to avoid casting issues, so the new generic path
is inconsistent and may introduce migration failures for columns with defaults.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1578-1596]

+                const newFullType = this.driver.createFullType(newColumn)
+                const oldFullType = this.driver.createFullType(oldColumn)
             upQueries.push(
                 new Query(
                     `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                         newColumn.name
-                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                        }" TYPE ${newFullType} USING "${
+                            newColumn.name
+                        }"::${newFullType}`,
                 ),
             )
             downQueries.push(
                 new Query(
                     `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                         newColumn.name
-                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                        }" TYPE ${oldFullType} USING "${
+                            newColumn.name
+                        }"::${oldFullType}`,
                 ),

Evidence

The new generic type/length/precision/scale change path adds a USING cast but does not touch column
defaults, so any existing DEFAULT remains in place during ALTER TYPE. In the same method, enum type
changes explicitly drop DEFAULT to avoid type-casting issues, and the generic default-update logic
only runs when the default expression changes—meaning type-only changes won’t adjust defaults at
all.

src/driver/postgres/PostgresQueryRunner.ts[1569-1597]
src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
src/driver/postgres/PostgresQueryRunner.ts[2218-2223]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PostgresQueryRunner.changeColumn` now uses `ALTER COLUMN ... TYPE ... USING` for type/length changes, but it leaves existing `DEFAULT` expressions in place. PostgreSQL can fail `ALTER COLUMN TYPE` when a column has a default that cannot be cast to the new type. TypeORM already mitigates this in the enum-type-change flow by dropping the default before the type change.
### Issue Context
- The new generic type/length/precision/scale change block adds a USING cast but does not drop/recreate defaults.
- Default updates later in the method only run when `newColumn.default !== oldColumn.default`, so type-only changes won’t re-apply defaults if we drop them.
- `executeMemoryDownSql()` runs `downQueries.reverse()`, so order of `downQueries.push(...)` matters.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1569-1598]
- src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
- src/driver/postgres/PostgresQueryRunner.ts[2218-2270]
### Implementation notes
- In the generic type-change block, if either old/new column has a default:
- set `defaultValueChanged = true`
- add an `upQueries` step to `DROP DEFAULT` **before** the `ALTER COLUMN ... TYPE ... USING` query
- add an `upQueries` step to `SET DEFAULT <newColumn.default>` (or keep dropped if new default is null/undefined) **after** the type change
- add corresponding `downQueries` that restore the old default (or drop it if old had none)
- Ensure you don’t double-apply defaults via the later default-update section (the `defaultValueChanged` flag should prevent that).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

PostgresQueryRunner now alters type/length via ALTER COLUMN ... TYPE ... USING, but it does not
drop/recreate an existing DEFAULT, which can make ALTER TYPE fail when the default can’t be cast.
TypeORM already drops DEFAULT for enum type changes to avoid casting issues, so the new generic path
is inconsistent and may introduce migration failures for columns with defaults.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1578-1596]

+                const newFullType = this.driver.createFullType(newColumn)
+                const oldFullType = this.driver.createFullType(oldColumn)
              upQueries.push(
                  new Query(
                      `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                          newColumn.name
-                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                        }" TYPE ${newFullType} USING "${
+                            newColumn.name
+                        }"::${newFullType}`,
                  ),
              )
              downQueries.push(
                  new Query(
                      `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                          newColumn.name
-                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                        }" TYPE ${oldFullType} USING "${
+                            newColumn.name
+                        }"::${oldFullType}`,
                  ),

Evidence

The new generic type/length/precision/scale change path adds a USING cast but does not touch column
defaults, so any existing DEFAULT remains in place during ALTER TYPE. In the same method, enum type
changes explicitly drop DEFAULT to avoid type-casting issues, and the generic default-update logic
only runs when the default expression changes—meaning type-only changes won’t adjust defaults at
all.

src/driver/postgres/PostgresQueryRunner.ts[1569-1597]
src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
src/driver/postgres/PostgresQueryRunner.ts[2218-2223]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PostgresQueryRunner.changeColumn` now uses `ALTER COLUMN ... TYPE ... USING` for type/length changes, but it leaves existing `DEFAULT` expressions in place. PostgreSQL can fail `ALTER COLUMN TYPE` when a column has a default that cannot be cast to the new type. TypeORM already mitigates this in the enum-type-change flow by dropping the default before the type change.
### Issue Context
- The new generic type/length/precision/scale change block adds a USING cast but does not drop/recreate defaults.
- Default updates later in the method only run when `newColumn.default !== oldColumn.default`, so type-only changes won’t re-apply defaults if we drop them.
- `executeMemoryDownSql()` runs `downQueries.reverse()`, so order of `downQueries.push(...)` matters.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1569-1598]
- src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
- src/driver/postgres/PostgresQueryRunner.ts[2218-2270]
### Implementation notes
- In the generic type-change block, if either old/new column has a default:
- set `defaultValueChanged = true`
- add an `upQueries` step to `DROP DEFAULT` **before** the `ALTER COLUMN ... TYPE ... USING` query
- add an `upQueries` step to `SET DEFAULT <newColumn.default>` (or keep dropped if new default is null/undefined) **after** the type change
- add corresponding `downQueries` that restore the old default (or drop it if old had none)
- Ensure you don’t double-apply defaults via the later default-update section (the `defaultValueChanged` flag should prevent that).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The added regression test exercises the new PostgreSQL USING-cast path via a length change, but it
doesn’t cover actual type conversions (nor default-casting scenarios). This leaves the highest-risk
edge case (type change + existing DEFAULT) unverified by tests.

Code

test/functional/query-runner/change-column.test.ts[R273-309]

+    it("should preserve data when changing column type or length", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                // SQLite does not impose length restrictions and handles types differently
+                if (DriverUtils.isSQLiteFamily(connection.driver)) return
+
+                // CockroachDB and Spanner may have restrictions on ALTER COLUMN TYPE
+                if (
+                    connection.driver.options.type === "cockroachdb" ||
+                    connection.driver.options.type === "spanner"
+                )
+                    return
+
+                const queryRunner = connection.createQueryRunner()
+                const postRepository = connection.getRepository(Post)
+
+                try {
+                    // Insert test data before modifying the column
+                    await postRepository.insert({
+                        id: 1,
+                        version: 1,
+                        name: "Test Post",
+                        text: "Some text",
+                        tag: "tag1",
+                    })
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )

Evi...

Description

Row cleanup and schema revert are inside the try block; if the test throws before reaching them, the
inserted row and/or schema change may remain and can contaminate subsequent tests within the same
run. Defensive cleanup should be moved to the finally block (best effort).

Code

test/functional/query-runner/change-column.test.ts[R287-336]

+                try {
+                    // Insert test data before modifying the column
+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )
+                    expect(rowsAfterLengthChange).to.have.length(1)
+                    expect(rowsAfterLengthChange[0]["name"]).to.equal(
+                        "Test Post",
+                    )
+
+                    // Verify column length was actually changed
+                    table = await queryRunner.getTable("post")
+                    table!
+                        .findColumnByName("name")!
+                        .length!.should.be.equal("500")
+
+                    // Revert changes and verify data is still intact
+                    await queryRunner.executeMemoryDownSql()
+
+                    const rowsAfterRevert = await connection.manager.query(
+                        `SELECT "name" FROM "post" WHERE "id" = 1`,
+                    )
+                    expect(rowsAfterRevert).to.have.length(1)
+                    expect(rowsAfterRevert[0]["name"]).to.equal("Test Post")
+
+                    // Clean up test data
+                    await connection.manager.query(
+                        `DELETE FROM "post" WHERE "id" = 1`,
+                    )
+                } finally {
+                    await queryRunner.release()
+                }

Evidence

The test guarantees only queryRunner.release() in finally. The row deletion and
executeMemoryDownSql() are in the try body, so they can be skipped on early failure/throw.

test/functional/query-runner/change-column.test.ts[287-336]
src/query-runner/BaseQueryRunner.ts[275-282]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Cleanup (row delete) and schema revert (`executeMemoryDownSql`) are executed inside the `try` body; an early throw (e.g., from `changeColumn` or an assertion) skips them.
### Issue Context
Within this `describe`, the schema is created once and reused across tests, so leftover rows/schema changes can contaminate subsequent tests in the same run.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[287-336]
### Suggested approach
- Track whether the row was inserted / column was changed.
- In `finally`, run best-effort cleanup:
- `await queryRunner.executeMemoryDownSql().catch(() => undefined)`
- delete the row (prefer repository/manager API; if raw SQL remains, ensure driver-portable quoting/parameters)
- then `await queryRunner.release()`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

PostgresQueryRunner now alters type/length via ALTER COLUMN ... TYPE ... USING, but it does not
drop/recreate an existing DEFAULT, which can make ALTER TYPE fail when the default can’t be cast.
TypeORM already drops DEFAULT for enum type changes to avoid casting issues, so the new generic path
is inconsistent and may introduce migration failures for columns with defaults.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1578-1596]

+                const newFullType = this.driver.createFullType(newColumn)
+                const oldFullType = this.driver.createFullType(oldColumn)
               upQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                        }" TYPE ${newFullType} USING "${
+                            newColumn.name
+                        }"::${newFullType}`,
                   ),
               )
               downQueries.push(
                   new Query(
                       `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
                           newColumn.name
-                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                        }" TYPE ${oldFullType} USING "${
+                            newColumn.name
+                        }"::${oldFullType}`,
                   ),

Evidence

The new generic type/length/precision/scale change path adds a USING cast but does not touch column
defaults, so any existing DEFAULT remains in place during ALTER TYPE. In the same method, enum type
changes explicitly drop DEFAULT to avoid type-casting issues, and the generic default-update logic
only runs when the default expression changes—meaning type-only changes won’t adjust defaults at
all.

src/driver/postgres/PostgresQueryRunner.ts[1569-1597]
src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
src/driver/postgres/PostgresQueryRunner.ts[2218-2223]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PostgresQueryRunner.changeColumn` now uses `ALTER COLUMN ... TYPE ... USING` for type/length changes, but it leaves existing `DEFAULT` expressions in place. PostgreSQL can fail `ALTER COLUMN TYPE` when a column has a default that cannot be cast to the new type. TypeORM already mitigates this in the enum-type-change flow by dropping the default before the type change.
### Issue Context
- The new generic type/length/precision/scale change block adds a USING cast but does not drop/recreate defaults.
- Default updates later in the method only run when `newColumn.default !== oldColumn.default`, so type-only changes won’t re-apply defaults if we drop them.
- `executeMemoryDownSql()` runs `downQueries.reverse()`, so order of `downQueries.push(...)` matters.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1569-1598]
- src/driver/postgres/PostgresQueryRunner.ts[1719-1744]
- src/driver/postgres/PostgresQueryRunner.ts[2218-2270]
### Implementation notes
- In the generic type-change block, if either old/new column has a default:
- set `defaultValueChanged = true`
- add an `upQueries` step to `DROP DEFAULT` **before** the `ALTER COLUMN ... TYPE ... USING` query
- add an `upQueries` step to `SET DEFAULT <newColumn.default>` (or keep dropped if new default is null/undefined) **after** the type change
- add corresponding `downQueries` that restore the old default (or drop it if old had none)
- Ensure you don’t double-apply defaults via the later default-update section (the `defaultValueChanged` flag should prevent that).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test uses raw SQL with double-quoted identifiers ("post", "name"), which is not portable to
MySQL/MariaDB (they typically require backticks) and can break CI for those drivers. Existing tests
use driver-specific quoting when issuing raw SQL, suggesting this new test should too (or avoid raw
SQL entirely).

Code

test/functional/query-runner/change-column.test.ts[R289-309]

+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )

Evidence

The test runs for all connections except SQLite/Cockroach/Spanner and executes raw SQL with
double-quoted identifiers. In this codebase, MySQL/MariaDB raw SQL in tests uses backticks, and the
MySQL query runner itself emits backticks for identifiers—indicating that hard-coding double quotes
is not the expected cross-driver syntax.

test/functional/query-runner/change-column.test.ts[272-333]
test/functional/query-runner/create-comment.test.ts[43-48]
src/driver/mysql/MysqlQueryRunner.ts[1113-1123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional test uses `connection.manager.query()` with SQL containing double-quoted identifiers (e.g. `INSERT INTO "post" ...`). This is not reliably portable across drivers (notably MySQL/MariaDB) and is inconsistent with existing tests that use backticks for MySQL/MariaDB raw SQL.
### Issue Context
This test runs across all created connections except SQLite/Cockroach/Spanner, so it must be driver-agnostic.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[272-336]
### Suggested approach
- Prefer using the entity API:
- `await connection.getRepository(Post).insert({...})`
- `await connection.getRepository(Post).findOneBy({ id: 1 })`
- `await connection.getRepository(Post).delete({ id: 1 })`
- If raw SQL is required, construct identifiers with the driver escape utilities and use parameters (avoid hard-coded quoting).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR fixes issue #3357, but the added functional regression test does not include an issue
reference comment near the test as requested. This reduces traceability from the test back to the
reported bug.

Code

test/functional/query-runner/change-column.test.ts[R273-285]

+    it("should preserve data when changing column type or length", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                // SQLite does not impose length restrictions and handles types differently
+                if (DriverUtils.isSQLiteFamily(connection.driver)) return
+
+                // CockroachDB and Spanner may have restrictions on ALTER COLUMN TYPE
+                if (
+                    connection.driver.options.type === "cockroachdb" ||
+                    connection.driver.options.type === "spanner"
+                )
+                    return
+

Evidence

Compliance ID 3 requests issue-reference comments in functional tests when applicable; the newly
added it("should preserve data...") block has no nearby #3357 reference.

Rule 3: Prefer functional tests over per-issue tests
test/functional/query-runner/change-column.test.ts[273-285]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional regression test for this fix does not include an issue reference comment (e.g., `#3357`) near the test.
## Issue Context
Compliance requires issue fixes to live in `test/functional` and to include an issue reference comment when applicable for traceability.
## Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[273-275]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The added regression test exercises the new PostgreSQL USING-cast path via a length change, but it
doesn’t cover actual type conversions (nor default-casting scenarios). This leaves the highest-risk
edge case (type change + existing DEFAULT) unverified by tests.

Code

test/functional/query-runner/change-column.test.ts[R273-309]

+    it("should preserve data when changing column type or length", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                // SQLite does not impose length restrictions and handles types differently
+                if (DriverUtils.isSQLiteFamily(connection.driver)) return
+
+                // CockroachDB and Spanner may have restrictions on ALTER COLUMN TYPE
+                if (
+                    connection.driver.options.type === "cockroachdb" ||
+                    connection.driver.options.type === "spanner"
+                )
+                    return
+
+                const queryRunner = connection.createQueryRunner()
+                const postRepository = connection.getRepository(Post)
+
+                try {
+                    // Insert test data before modifying the column
+                    await postRepository.insert({
+                        id: 1,
+                        version: 1,
+                        name: "Test Post",
+                        text: "Some text",
+                        tag: "tag1",
+                    })
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )

Evidence

The new test case only changes the column length and never changes TableColumn.type, so it won’t
catch failures specific to type conversions (e.g., default casting) introduced by the new ALTER TYPE
... USING path.

test/functional/query-runner/change-column.test.ts[273-309]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new regression test validates length changes but not true type conversions (e.g., `int` → `text`, `varchar` → `int`). The new Postgres `ALTER COLUMN ... TYPE ... USING` path is most likely to break on type conversions, especially when defaults exist.
### Issue Context
- The test name claims "type or length", but current coverage is length-only.
- A type-conversion test would also surface default-casting problems.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[273-343]
### Suggested test additions
- Add a second sub-case in the same test (or a new test) that:
- adds/ensures a default on a column (or uses an existing default column)
- changes `TableColumn.type` (e.g., `varchar` → `text`, or `int` → `bigint`) using `changeColumn`
- verifies data is preserved after the type change and after `executeMemoryDownSql()`
- Keep driver skips where type conversion is known unsupported, but avoid over-skipping drivers that should support the scenario.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Row cleanup and schema revert are inside the try block; if the test throws before reaching them, the
inserted row and/or schema change may remain and can contaminate subsequent tests within the same
run. Defensive cleanup should be moved to the finally block (best effort).

Code

test/functional/query-runner/change-column.test.ts[R287-336]

+                try {
+                    // Insert test data before modifying the column
+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )
+                    expect(rowsAfterLengthChange).to.have.length(1)
+                    expect(rowsAfterLengthChange[0]["name"]).to.equal(
+                        "Test Post",
+                    )
+
+                    // Verify column length was actually changed
+                    table = await queryRunner.getTable("post")
+                    table!
+                        .findColumnByName("name")!
+                        .length!.should.be.equal("500")
+
+                    // Revert changes and verify data is still intact
+                    await queryRunner.executeMemoryDownSql()
+
+                    const rowsAfterRevert = await connection.manager.query(
+                        `SELECT "name" FROM "post" WHERE "id" = 1`,
+                    )
+                    expect(rowsAfterRevert).to.have.length(1)
+                    expect(rowsAfterRevert[0]["name"]).to.equal("Test Post")
+
+                    // Clean up test data
+                    await connection.manager.query(
+                        `DELETE FROM "post" WHERE "id" = 1`,
+                    )
+                } finally {
+                    await queryRunner.release()
+                }

Evidence

The test guarantees only queryRunner.release() in finally. The row deletion and
executeMemoryDownSql() are in the try body, so they can be skipped on early failure/throw.

test/functional/query-runner/change-column.test.ts[287-336]
src/query-runner/BaseQueryRunner.ts[275-282]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Cleanup (row delete) and schema revert (`executeMemoryDownSql`) are executed inside the `try` body; an early throw (e.g., from `changeColumn` or an assertion) skips them.
### Issue Context
Within this `describe`, the schema is created once and reused across tests, so leftover rows/schema changes can contaminate subsequent tests in the same run.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[287-336]
### Suggested approach
- Track whether the row was inserted / column was changed.
- In `finally`, run best-effort cleanup:
- `await queryRunner.executeMemoryDownSql().catch(() => undefined)`
- delete the row (prefer repository/manager API; if raw SQL remains, ensure driver-portable quoting/parameters)
- then `await queryRunner.release()`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new functional test silently ignores failures via .catch(() => undefined) during cleanup,
which can hide real regressions and makes failures harder to diagnose. This introduces abnormal
defensive error-handling inconsistent with the rest of the suite.

Code

test/functional/query-runner/change-column.test.ts[R333-340]

+                    // Best-effort cleanup regardless of test outcome
+                    await queryRunner
+                        .executeMemoryDownSql()
+                        .catch(() => undefined)
+                    await postRepository
+                        .delete({ id: 1 })
+                        .catch(() => undefined)
+                    await queryRunner.release()

Evidence

Compliance ID 4 disallows abnormal defensive try/catch patterns and noise; the added cleanup
explicitly suppresses errors by catching and discarding them.

Rule 4: Remove AI-generated noise
test/functional/query-runner/change-column.test.ts[333-340]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new test cleanup uses `.catch(() => undefined)` which silently ignores cleanup failures and adds abnormal defensive error handling.
## Issue Context
Other tests in this file typically call `executeMemoryDownSql()` and `release()` without swallowing errors; suppressing errors can hide regressions and makes debugging harder.
## Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[333-340]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR fixes issue #3357, but the added functional regression test does not include an issue
reference comment near the test as requested. This reduces traceability from the test back to the
reported bug.

Code

test/functional/query-runner/change-column.test.ts[R273-285]

+    it("should preserve data when changing column type or length", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                // SQLite does not impose length restrictions and handles types differently
+                if (DriverUtils.isSQLiteFamily(connection.driver)) return
+
+                // CockroachDB and Spanner may have restrictions on ALTER COLUMN TYPE
+                if (
+                    connection.driver.options.type === "cockroachdb" ||
+                    connection.driver.options.type === "spanner"
+                )
+                    return
+

Evidence

Compliance ID 3 requests issue-reference comments in functional tests when applicable; the newly
added it("should preserve data...") block has no nearby #3357 reference.

Rule 3: Prefer functional tests over per-issue tests
test/functional/query-runner/change-column.test.ts[273-285]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new functional regression test for this fix does not include an issue reference comment (e.g., `#3357`) near the test.
## Issue Context
Compliance requires issue fixes to live in `test/functional` and to include an issue reference comment when applicable for traceability.
## Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[273-275]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The added regression test exercises the new PostgreSQL USING-cast path via a length change, but it
doesn’t cover actual type conversions (nor default-casting scenarios). This leaves the highest-risk
edge case (type change + existing DEFAULT) unverified by tests.

Code

test/functional/query-runner/change-column.test.ts[R273-309]

+    it("should preserve data when changing column type or length", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                // SQLite does not impose length restrictions and handles types differently
+                if (DriverUtils.isSQLiteFamily(connection.driver)) return
+
+                // CockroachDB and Spanner may have restrictions on ALTER COLUMN TYPE
+                if (
+                    connection.driver.options.type === "cockroachdb" ||
+                    connection.driver.options.type === "spanner"
+                )
+                    return
+
+                const queryRunner = connection.createQueryRunner()
+                const postRepository = connection.getRepository(Post)
+
+                try {
+                    // Insert test data before modifying the column
+                    await postRepository.insert({
+                        id: 1,
+                        version: 1,
+                        name: "Test Post",
+                        text: "Some text",
+                        tag: "tag1",
+                    })
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )

Evidence

The new test case only changes the column length and never changes TableColumn.type, so it won’t
catch failures specific to type conversions (e.g., default casting) introduced by the new ALTER TYPE
... USING path.

test/functional/query-runner/change-column.test.ts[273-309]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new regression test validates length changes but not true type conversions (e.g., `int` → `text`, `varchar` → `int`). The new Postgres `ALTER COLUMN ... TYPE ... USING` path is most likely to break on type conversions, especially when defaults exist.
### Issue Context
- The test name claims "type or length", but current coverage is length-only.
- A type-conversion test would also surface default-casting problems.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[273-343]
### Suggested test additions
- Add a second sub-case in the same test (or a new test) that:
- adds/ensures a default on a column (or uses an existing default column)
- changes `TableColumn.type` (e.g., `varchar` → `text`, or `int` → `bigint`) using `changeColumn`
- verifies data is preserved after the type change and after `executeMemoryDownSql()`
- Keep driver skips where type conversion is known unsupported, but avoid over-skipping drivers that should support the scenario.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Row cleanup and schema revert are inside the try block; if the test throws before reaching them, the
inserted row and/or schema change may remain and can contaminate subsequent tests within the same
run. Defensive cleanup should be moved to the finally block (best effort).

Code

test/functional/query-runner/change-column.test.ts[R287-336]

+                try {
+                    // Insert test data before modifying the column
+                    await connection.manager.query(
+                        `INSERT INTO "post" ("id", "version", "name", "text", "tag") VALUES (1, 1, 'Test Post', 'Some text', 'tag1')`,
+                    )
+
+                    let table = await queryRunner.getTable("post")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change column length (e.g., varchar(255) -> varchar(500))
+                    const changedNameColumn = nameColumn.clone()
+                    changedNameColumn.length = "500"
+                    await queryRunner.changeColumn(
+                        table!,
+                        nameColumn,
+                        changedNameColumn,
+                    )
+
+                    // Verify data is preserved after length change
+                    const rowsAfterLengthChange =
+                        await connection.manager.query(
+                            `SELECT "name" FROM "post" WHERE "id" = 1`,
+                        )
+                    expect(rowsAfterLengthChange).to.have.length(1)
+                    expect(rowsAfterLengthChange[0]["name"]).to.equal(
+                        "Test Post",
+                    )
+
+                    // Verify column length was actually changed
+                    table = await queryRunner.getTable("post")
+                    table!
+                        .findColumnByName("name")!
+                        .length!.should.be.equal("500")
+
+                    // Revert changes and verify data is still intact
+                    await queryRunner.executeMemoryDownSql()
+
+                    const rowsAfterRevert = await connection.manager.query(
+                        `SELECT "name" FROM "post" WHERE "id" = 1`,
+                    )
+                    expect(rowsAfterRevert).to.have.length(1)
+                    expect(rowsAfterRevert[0]["name"]).to.equal("Test Post")
+
+                    // Clean up test data
+                    await connection.manager.query(
+                        `DELETE FROM "post" WHERE...