Use ALTER COLUMN TYPE for data preservation

• Remove type/length/isArray from destructive DROP+ADD condition
• Add ALTER COLUMN TYPE logic for type/length/array changes
• Preserve data using safe ALTER instead of recreation
• Keep DROP+ADD only for generated/computed column changes

src/driver/cockroachdb/CockroachQueryRunner.ts

Use MODIFY for type/length preservation

• Remove type/length from destructive DROP+ADD condition
• Add ALTER TABLE MODIFY logic for type/length changes
• Preserve data using safe MODIFY instead of recreation
• Keep DROP+ADD only for IDENTITY and computed column changes

src/driver/oracle/OracleQueryRunner.ts

Use ALTER COLUMN TYPE for type changes

• Move type/length/isArray checks into else block for safe ALTER
• Use ALTER COLUMN TYPE for type/length/array changes
• Keep DROP+ADD only for name changes (Spanner lacks RENAME COLUMN)
• Preserve data for non-rename column modifications

src/driver/spanner/SpannerQueryRunner.ts

Add tests for column change data preservation

• Add test for type/length change data preservation (varchar 50→100)
• Add test for simultaneous rename+type change with data verification
• Test runs on all drivers except Spanner (which requires recreation for renames)
• Verify schema changes and row data integrity after ALTER operations

test/functional/query-runner/change-column.test.ts

Description

In Postgres/CockroachDB changeColumn, the new lengthOnlyChanged branch replaces the cached
column with newColumn.clone() even when the column is also being renamed, which can remove the
old-name column from clonedTable. The later rename block then fails to find the old column in
clonedTable and can throw by updating clonedTable.columns[-1] during migrations.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1333-1359]

+            if (lengthOnlyChanged) {
+                // Only the length changed within the same base type (e.g. varchar(50)
+                // → varchar(200)).  Use ALTER COLUMN ... TYPE so existing row data is
+                // preserved instead of being discarded by DROP + ADD.
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
+                            oldColumn.name
+                        }" TYPE ${this.driver.createFullType(newColumn)}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${
+                            oldColumn.name
+                        }" TYPE ${this.driver.createFullType(oldColumn)}`,
+                    ),
+                )
+
+                // Update clonedTable so replaceCachedTable() propagates the
+                // correct column definition.
+                const clonedColIdx = clonedTable.columns.findIndex(
+                    (c) => c.name === oldColumn.name,
+                )
+                if (clonedColIdx !== -1)
+                    clonedTable.columns[clonedColIdx] = newColumn.clone()
+            }

Evidence

lengthOnlyChanged does not check the column name, so it can execute during a rename+length change.
That block updates clonedTable.columns[clonedColIdx] = newColumn.clone(), and
TableColumn.clone() copies the *new* name, so the old-name column may no longer exist in
clonedTable. The subsequent rename logic assumes a column with oldColumn.name exists in
clonedTable and uses a non-null assertion (oldTableColumn!), which can yield `indexOf(undefined)
=== -1 and then attempts to write clonedTable.columns[-1].name`, causing a runtime error.
CockroachDB has the same pattern.

src/driver/postgres/PostgresQueryRunner.ts[1304-1359]
src/driver/postgres/PostgresQueryRunner.ts[1627-1635]
src/schema-builder/table/TableColumn.ts[183-210]
src/driver/cockroachdb/CockroachQueryRunner.ts[1410-1435]
src/driver/cockroachdb/CockroachQueryRunner.ts[1668-1676]

Agent prompt

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

## Issue description
Postgres/Cockroach `changeColumn()` updates `clonedTable` with `newColumn.clone()` in the `lengthOnlyChanged` branch even when the column is also being renamed. Because `clone()` copies the new name, the later rename block may not find the old-name column in `clonedTable`, leading to an invalid `indexOf(oldTableColumn!)` and potential runtime crash.
### Issue Context
The new ALTER TYPE path is correct SQL-wise, but the in-memory table cache (`clonedTable`) must be updated in a way that preserves the rename workflow.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1304-1360]
- src/driver/postgres/PostgresQueryRunner.ts[1627-1635]
- src/driver/cockroachdb/CockroachQueryRunner.ts[1380-1436]
- src/driver/cockroachdb/CockroachQueryRunner.ts[1668-1676]
### Expected fix approach
Adjust the `lengthOnlyChanged` cache update so it does not change the cached column name before the rename block runs. For example:
- Only update the cached column definition when `oldColumn.name === newColumn.name`, **or**
- When renaming, update cached type/length while keeping `name = oldColumn.name` until after the rename block, **or**
- Defer updating `clonedTable` to `newColumn.clone()` until after `oldColumn.name` and `clonedTable` have been renamed.
Ensure rename+length tests work on Postgres and CockroachDB.

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

Description

AuroraMysqlQueryRunner now routes column type changes through an in-place ALTER TABLE ... CHANGE
path, while MysqlQueryRunner still forces DROP + ADD for base type changes. This creates
inconsistent migration behavior between MySQL and Aurora MySQL for the same schema diff and may
cause Aurora migrations to fail where MySQL recreates the column.

Code

src/driver/aurora-mysql/AuroraMysqlQueryRunner.ts[R851-856]

if (
   (newColumn.isGenerated !== oldColumn.isGenerated &&
       newColumn.generationStrategy !== "uuid") ||
-            oldColumn.type !== newColumn.type ||
-            oldColumn.length !== newColumn.length ||
   oldColumn.generatedType !== newColumn.generatedType
) {
   await this.dropColumn(table, oldColumn)

Evidence

MySQL explicitly treats oldColumn.type !== newColumn.type as requiring column recreation, but
Aurora removed the type-check from its recreate branch and includes type changes in
typeOrLengthChanged, issuing ALTER TABLE ... CHANGE ... instead.

src/driver/aurora-mysql/AuroraMysqlQueryRunner.ts[851-890]
src/driver/mysql/MysqlQueryRunner.ts[1110-1125]

Agent prompt

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

## Issue description
AuroraMysqlQueryRunner currently alters column *type* in-place via `ALTER TABLE ... CHANGE` (data-preserving path). MysqlQueryRunner, for the same engine family, treats base type changes as requiring `DROP + ADD` recreation.
This divergence means a migration generated for a type change can behave differently on Aurora vs MySQL.
## Issue Context
- Aurora path: `typeOrLengthChanged` includes `oldColumn.type !== newColumn.type` and triggers `ALTER TABLE ... CHANGE`.
- MySQL path: `oldColumn.type !== newColumn.type` is in the `DROP + ADD` branch.
## Fix Focus Areas
- src/driver/aurora-mysql/AuroraMysqlQueryRunner.ts[851-890]
- src/driver/mysql/MysqlQueryRunner.ts[1110-1125]
## Suggested fix
Make Aurora follow the same rule as MySQL:
1. Put `oldColumn.type !== newColumn.type` back into the `DROP + ADD` condition for Aurora.
2. Restrict the non-destructive `CHANGE old->old` path to length-only changes (and rename+length via atomic `CHANGE old->new`).
3. (Optional but recommended) Add/extend tests to cover a true type change on MySQL-family drivers to ensure intended behavior is stable.

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

Description

Several changeColumn implementations now execute ALTER/CHANGE for type/length changes but do not
update clonedTable.columns before calling replaceCachedTable, leaving QueryRunner.loadedTables with
the old type/length. Subsequent schema operations that rely on the cached Table can operate on
incorrect column definitions.

Code

src/driver/mysql/MysqlQueryRunner.ts[R1129-1159]

+            // At this point oldColumn.type === newColumn.type (type change was handled above).
+            const lengthOnlyChanged =
+                oldColumn.length !== newColumn.length
+
+            if (lengthOnlyChanged && newColumn.name === oldColumn.name) {
+                // Only the length changed within the same base type (e.g. varchar(50)
+                // → varchar(200)).  Use CHANGE to preserve existing row data instead
+                // of the destructive DROP + ADD path.
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} CHANGE \`${
+                            oldColumn.name
+                        }\` \`${oldColumn.name}\` ${this.buildCreateColumnSql(
+                            newColumn,
+                            true,
+                            true,
+                        )}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} CHANGE \`${
+                            oldColumn.name
+                        }\` \`${oldColumn.name}\` ${this.buildCreateColumnSql(
+                            oldColumn,
+                            true,
+                            true,
+                        )}`,
+                    ),
+                )
+            }

Evidence

In MysqlQueryRunner, the DROP+ADD path refreshes clonedTable from the updated table, but the new
length-only ALTER/CHANGE path only pushes SQL queries and never updates clonedTable before
replaceCachedTable, so the cache keeps the old column definition. BaseQueryRunner.replaceCachedTable
overwrites the cached table’s columns with clonedTable.columns, and Table.clone deep-clones columns,
so missing updates to clonedTable persist in the cache. The same pattern exists in other modified
drivers (e.g., Postgres/Cockroach/Spanner) where ALTER COLUMN TYPE is added but clonedTable is not
updated before replaceCachedTable.

src/driver/mysql/MysqlQueryRunner.ts[1110-1128]
src/driver/mysql/MysqlQueryRunner.ts[1129-1159]
src/driver/mysql/MysqlQueryRunner.ts[1648-1649]
src/query-runner/BaseQueryRunner.ts[353-378]
src/schema-builder/table/Table.ts[165-183]
src/driver/postgres/PostgresQueryRunner.ts[1333-1351]
src/driver/postgres/PostgresQueryRunner.ts[2475-2476]
src/driver/spanner/SpannerQueryRunner.ts[894-916]
src/driver/spanner/SpannerQueryRunner.ts[1000-1001]

Agent prompt

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

## Issue description
New non-destructive ALTER/CHANGE paths update the database schema but leave `clonedTable` (and thus `QueryRunner.loadedTables`) with the *old* column type/length/etc, because `clonedTable.columns` is never updated to match `newColumn` before `replaceCachedTable()`.
### Issue Context
`replaceCachedTable()` overwrites the cached table’s `columns` with `changedTable.columns`. `Table.clone()` deep-clones columns, so you must explicitly mutate/replace the corresponding `TableColumn` inside `clonedTable` when you apply an in-place ALTER.
### Fix Focus Areas
- src/driver/mysql/MysqlQueryRunner.ts[1129-1160]
- src/driver/mysql/MysqlQueryRunner.ts[1648-1649]
- src/driver/aurora-mysql/AuroraMysqlQueryRunner.ts[862-917]
- src/driver/postgres/PostgresQueryRunner.ts[1333-1351]
- src/driver/postgres/PostgresQueryRunner.ts[2475-2476]
- src/driver/cockroachdb/CockroachQueryRunner.ts[1410-1427]
- src/driver/cockroachdb/CockroachQueryRunner.ts[2183-2184]
- src/driver/spanner/SpannerQueryRunner.ts[894-916]
- src/driver/spanner/SpannerQueryRunner.ts[1000-1001]
### Implementation notes
For each ALTER/CHANGE branch that bypasses DROP+ADD:
1. Find the corresponding column in `clonedTable` (by old name or new name depending on rename ordering).
2. Copy/replace the column definition fields that were altered (at minimum `type`, `length`, `precision`, `scale`, `unsigned`, `isArray`, and any other driver-relevant fields).
3. Ensure rename paths update both the column name and the definition.

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

Description

MysqlQueryRunner.changeColumn no longer drops+adds on type changes, but the new ALTER path only runs
for length-only changes; a pure type change (same name, same other properties) can generate no SQL,
leaving the column type unchanged.

Code

src/driver/mysql/MysqlQueryRunner.ts[R1126-1133]

+            const lengthOnlyChanged =
+                oldColumn.type === newColumn.type &&
+                oldColumn.length !== newColumn.length
+
+            if (lengthOnlyChanged && newColumn.name === oldColumn.name) {
+                // Only the length changed within the same base type (e.g. varchar(50)
+                // → varchar(200)).  Use CHANGE to preserve existing row data instead
+                // of the destructive DROP + ADD path.

Evidence

In MysqlQueryRunner, the new shortcut only triggers when type is unchanged and length differs. For a
pure type change, execution falls through to isColumnChanged(), but BaseQueryRunner.isColumnChanged
explicitly does not check type/length, so it can return false and no ALTER is queued.

src/driver/mysql/MysqlQueryRunner.ts[1110-1156]
src/driver/mysql/MysqlQueryRunner.ts[1327-1341]
src/query-runner/BaseQueryRunner.ts[540-596]

Agent prompt

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

## Issue description
`MysqlQueryRunner.changeColumn()` no longer performs any operation for a **pure type change** (e.g. `int` → `bigint`) when the column name and other properties are unchanged. This happens because:
- the new special-case only handles length-only changes, and
- the remaining change-detection (`isColumnChanged`) intentionally ignores type/length.
### Issue Context
`BaseQueryRunner.isColumnChanged()` explicitly does not check column `type`/`length`, assuming drivers handle those separately.
### Fix Focus Areas
- Update MySQL changeColumn logic to treat **type OR length** changes as needing an explicit `ALTER TABLE ... CHANGE` statement (similar to AuroraMysqlQueryRunner).
- Ensure you don’t double-emit CHANGE statements (adjust the later `isColumnChanged` guard accordingly).
- src/driver/mysql/MysqlQueryRunner.ts[1110-1171]
- src/driver/mysql/MysqlQueryRunner.ts[1327-1341]
- src/query-runner/BaseQueryRunner.ts[540-596]

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

Description

OracleQueryRunner.changeColumn only emits ALTER TABLE ... MODIFY for length-only changes (same
type), so a pure type change can generate no SQL and the column type will not be updated.

Code

src/driver/oracle/OracleQueryRunner.ts[R1145-1165]

+            const lengthOnlyChanged =
+                oldColumn.type === newColumn.type &&
+                oldColumn.length !== newColumn.length
+            if (lengthOnlyChanged) {
+                // Only the length changed within the same base type: use MODIFY to
+                // preserve existing row data instead of DROP + ADD.
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} MODIFY "${
+                            oldColumn.name
+                        }" ${this.driver.createFullType(newColumn)}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} MODIFY "${
+                            oldColumn.name
+                        }" ${this.driver.createFullType(oldColumn)}`,
+                    ),
+                )
+            }

Evidence

OracleQueryRunner’s new shortcut only runs when oldColumn.type === newColumn.type and length
differs. For type changes, the code falls through to isColumnChanged, but
BaseQueryRunner.isColumnChanged does not evaluate type/length, so a type-only change can be treated
as “no change” and no SQL is generated.

src/driver/oracle/OracleQueryRunner.ts[1129-1165]
src/query-runner/BaseQueryRunner.ts[540-596]

Agent prompt

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

## Issue description
`OracleQueryRunner.changeColumn()` no longer guarantees a SQL statement for **type-only** changes (same name, no other property differences). Since `isColumnChanged()` ignores type/length, Oracle can silently skip the requested type change.
### Issue Context
`BaseQueryRunner.isColumnChanged()` is designed to exclude type/length from change detection; drivers must handle those explicitly.
### Fix Focus Areas
- Add an explicit Oracle path for `typeOrLengthChanged` (at least `oldColumn.type !== newColumn.type || oldColumn.length !== newColumn.length`) that emits `ALTER TABLE ... MODIFY` using `createFullType(newColumn)` (and a matching down query).
- Keep the existing identity/type-change recreation rule.
- src/driver/oracle/OracleQueryRunner.ts[1129-1165]
- src/query-runner/BaseQueryRunner.ts[540-596]

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

Description

OracleQueryRunner skips its default/nullability update block whenever lengthOnlyChanged is true, but
the new length-only MODIFY statement only changes the datatype, so combined changes (length +
default/nullability) will be partially applied.

Code

src/driver/oracle/OracleQueryRunner.ts[R1379-1382]

+            if (!lengthOnlyChanged && this.isColumnChanged(oldColumn, newColumn, true)) {
   let defaultUp: string = ""
   let defaultDown: string = ""
   let nullableUp: string = ""

Evidence

The length-only path emits ALTER TABLE ... MODIFY "col" ${createFullType(newColumn)} (datatype
only). The code that computes and applies DEFAULT ... and NULL/NOT NULL is inside the
isColumnChanged block, which is gated by !lengthOnlyChanged, so those updates are skipped when
length changes too.

src/driver/oracle/OracleQueryRunner.ts[1145-1165]
src/driver/oracle/OracleQueryRunner.ts[1379-1405]

Agent prompt

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

## Issue description
When `lengthOnlyChanged` is true, Oracle emits a datatype-only `MODIFY` and then **skips** the `isColumnChanged()` block that applies default/nullability changes. If a migration changes `length` plus `default` and/or `isNullable` in the same step, Oracle will not apply the non-type changes.
### Issue Context
Oracle’s length-only SQL uses `createFullType()` (datatype only). Default/nullability handling is implemented separately inside the `isColumnChanged` block.
### Fix Focus Areas
- Refine `lengthOnlyChanged` usage so it only bypasses the `isColumnChanged` block when *no other properties* changed (e.g., `lengthOnlyChanged && !this.isColumnChanged(oldColumn, newColumn, true)`), OR
- Remove the `!lengthOnlyChanged` guard and allow both the type/length MODIFY and the default/nullability modifications to run when needed.
- src/driver/oracle/OracleQueryRunner.ts[1145-1165]
- src/driver/oracle/OracleQueryRunner.ts[1379-1405]
- src/query-runner/BaseQueryRunner.ts[540-596]

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

Description

MysqlQueryRunner.changeColumn can emit two ALTER TABLE ... CHANGE statements for a single
length-only change: the newly-added lengthOnlyChanged block and the existing isColumnChanged() block
both enqueue a CHANGE. This can cause an extra table rebuild/lock during migrations and doubles the
DDL work for the same schema change.

Code

src/driver/mysql/MysqlQueryRunner.ts[R1126-1156]

+            const lengthOnlyChanged =
+                oldColumn.type === newColumn.type &&
+                oldColumn.length !== newColumn.length
+
+            if (lengthOnlyChanged && newColumn.name === oldColumn.name) {
+                // Only the length changed within the same base type (e.g. varchar(50)
+                // → varchar(200)).  Use CHANGE to preserve existing row data instead
+                // of the destructive DROP + ADD path.
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} CHANGE \`${
+                            oldColumn.name
+                        }\` \`${oldColumn.name}\` ${this.buildCreateColumnSql(
+                            newColumn,
+                            true,
+                            true,
+                        )}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(table)} CHANGE \`${
+                            oldColumn.name
+                        }\` \`${oldColumn.name}\` ${this.buildCreateColumnSql(
+                            oldColumn,
+                            true,
+                            true,
+                        )}`,
+                    ),
+                )
+            }

Evidence

The new lengthOnlyChanged branch always adds an ALTER TABLE ... CHANGE when the name is unchanged
and only the length differs; later in the same method, the existing
isColumnChanged(oldColumn,newColumn,...) block still runs and also adds an ALTER TABLE ... CHANGE
when any column attribute differs (including length). With a length-only change and no rename, both
branches run and enqueue two CHANGE statements.

src/driver/mysql/MysqlQueryRunner.ts[1126-1156]
src/driver/mysql/MysqlQueryRunner.ts[1327-1341]

Agent prompt

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

## Issue description
`MysqlQueryRunner.changeColumn()` now pushes an extra `ALTER TABLE ... CHANGE` for length-only changes, but the method already pushes a `CHANGE` via the existing `isColumnChanged(...)` block. This results in two DDL operations for one logical change.
### Issue Context
This can double table rebuild/lock time in production migrations and generates noisier migration SQL.
### Fix Focus Areas
- src/driver/mysql/MysqlQueryRunner.ts[1126-1156]
- src/driver/mysql/MysqlQueryRunner.ts[1327-1341]
### Suggested fix
Either:
1) Remove the new `lengthOnlyChanged` block entirely and rely on the existing `isColumnChanged(...)` path (now that DROP+ADD is no longer forced for type/length changes), **or**
2) If keeping the new block, add a guard so `isColumnChanged(...)` does not enqueue another `CHANGE` when the same alteration was already emitted (e.g., track a boolean like `alreadyAlteredTypeOrLength`).

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

Description

The new change-column tests access raw SELECT results via rows[0].description and rows[0].new_col,
but OracleQueryRunner returns raw rows without normalizing column-name casing and Oracle column
names are sourced from COLUMN_NAME. This likely makes those properties undefined on Oracle, causing
the tests to fail on that driver.

Code

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

+                // Data must be preserved — the ALTER must not have dropped the column
+                const rows = await queryRunner.query(
+                    `SELECT * FROM issue_3357 WHERE id = 1`,
+                )
+                rows.length.should.be.equal(1)
+                rows[0].description.should.be.equal("hello")
+

Evidence

The tests assert on lowercase object keys from queryRunner.query(...) results. OracleQueryRunner
assigns result.records = raw.rows directly (no key normalization), and Oracle schema reading
assigns TableColumn.name from dbColumn["COLUMN_NAME"], indicating the driver uses DB-provided
column-name casing; therefore a lowercase property access in a cross-driver raw query test is
inconsistent for Oracle.

test/functional/query-runner/change-column.test.ts[334-340]
test/functional/query-runner/change-column.test.ts[410-416]
src/driver/oracle/OracleQueryRunner.ts[197-276]
src/driver/oracle/OracleQueryRunner.ts[2642-2644]

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 tests read raw query results using lowercase keys (`rows[0].description`, `rows[0].new_col`). OracleQueryRunner returns raw rows without normalizing column keys, so these assertions are not portable to Oracle.
### Issue Context
`queryRunner.query()` is driver-specific in its raw result shape. For cross-driver functional tests, assertions should either normalize keys or select with driver-appropriate aliases.
### Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[334-340]
- test/functional/query-runner/change-column.test.ts[410-416]
### Suggested fix
Use a small helper to read a column value case-insensitively, e.g.:

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

Description

The new functional tests cast the table definition to any, bypassing TypeScript type checking.
This violates the requirement to avoid any-casts used to bypass types.

Code

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

+                    } as any,

Evidence

Compliance ID 4 forbids adding any-casts to bypass types; the new test code explicitly uses `} as
any, when calling queryRunner.createTable(...)`.

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

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 tests use `as any` to coerce the `createTable` argument, which bypasses TypeScript type safety.
## Issue Context
Compliance requires avoiding `any`-casts used to bypass types in new changes.
## Fix Focus Areas
- test/functional/query-runner/change-column.test.ts[281-299]
- test/functional/query-runner/change-column.test.ts[348-366]

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

Description

In PostgresQueryRunner.changeColumn, the type-change block restores the default using newColumn.name
before the RENAME COLUMN query executes, so the generated SQL references a column name that does not
yet exist and the migration fails.

Code

src/driver/postgres/PostgresQueryRunner.ts[R1361-1382]

+                // Restore default after type change
+                if (
+                    oldColumn.type !== newColumn.type &&
+                    newColumn.default !== null &&
+                    newColumn.default !== undefined
+                ) {
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" SET DEFAULT ${newColumn.default}`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" DROP DEFAULT`,
+                        ),
+                    )
+                }
+            }
+
if (oldColumn.name !== newColumn.name) {
// rename column
upQueries.push(

Evidence

The code pushes SET DEFAULT targeting "${newColumn.name}" inside the type-change block, but the
rename statement is appended later; because upQueries are executed in push order, SET DEFAULT runs
before the rename and therefore targets a non-existent column name whenever a rename is part of the
same changeColumn operation.

src/driver/postgres/PostgresQueryRunner.ts[1314-1395]

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` generates invalid SQL when a column is *both* renamed and has a type change requiring default drop/restore: it emits `ALTER COLUMN "${newColumn.name}" SET DEFAULT ...` before emitting the `RENAME COLUMN` statement, so the `SET DEFAULT` references a column that does not exist yet.
### Issue Context
In `changeColumn`, upQueries are executed in the same order they are pushed. The current implementation pushes (1) DROP DEFAULT (old name), (2) ALTER TYPE (old name), (3) SET DEFAULT (new name), and only later pushes (4) RENAME COLUMN.
### Fix Focus Areas
- src/driver/postgres/PostgresQueryRunner.ts[1314-1395]
### Suggested change
- In the "Restore default after type change" section, use `oldColumn.name` instead of `newColumn.name` for both the up `SET DEFAULT` and the down `DROP DEFAULT` statements **OR** postpone these default statements until after the rename when `oldColumn.name !== newColumn.name`.

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