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)