Prisma v4 breaks support for empty `dbgenerated()` - invalid migration created with no schema change

Bug description

Using Postgres generated columns via @default(dbgenerated()) with custom Postgres GENERATED AWAYS AS ... STORED SQL in migration worked just fine through Prisma v3; breaks with Prisma 4.0.0 onwards.

Reproduction repo: https://github.com/andyjy/prisma-dbgenerated-bug-repro

Reproduction details:

schema.prisma:

model table {
    id String @id
    hereBeDragons String @default(dbgenerated())
}

…with custom migration to use Postgres generated field:

migration.sql:

CREATE TABLE "table" (
    ...

    -- manually edited migration to make column generated
    "hereBeDragons" TEXT NOT NULL GENERATED ALWAYS AS (
'this row ID is: '::text || "id") STORED,

    ...

Worked just fine through prisma 3.15.2; prisma 4.0.0 onwards produces invalid migration with no schema change that attempts to DROP DEFAULT (which we don’t want to do, and fails since Postgres generated columns require use of DROP EXPRESSION if we were actually to want to convert the generated column to a normal one).

...invalid_failed_migration/migration.sql:

ALTER TABLE "table" ALTER COLUMN "hereBeDragons" DROP DEFAULT;

(unwanted new migration fails with error:)

Database error code: 42601

Database error:
ERROR: column "hereBeDragons" of relation "table" is a generated column
HINT: Use ALTER TABLE ... ALTER COLUMN ... DROP EXPRESSION instead.

How to reproduce

Reproduction repo: https://github.com/andyjy/prisma-dbgenerated-bug-repro

Expected behavior

Prisma 4 continues to support this schema and migration history with no attempt to generate a new migration dropping the default value for the column.

Prisma information

Schema above + in reproduction repo

Environment & setup

• OS: MacOS
• Database: PostgreSQL
• Node.js version: v16.16.0

Prisma Version

works up to 3.15.2, fails since 4.0.0 (tested up to 4.2.1)

[andyjy]

now enjoying the fix in 4.4.0 - thanks @tomhoule 🙏

[tomhoule]

Due to CI issues, the version of prisma-engines that was released in 4.3.0 is a bit older and does not contain this fix, sadly. So it is merged on main, it will be on 4.4.0 dev versions and in the 4.4.0 release, but it won’t be in 4.3.0.