Empty `dbgenerated()` still breaking for `Unsupported()` types

Bug description

Using a default(dbgenerated()) on a column with type Unsupported("...") where a Postgres generated column is manually added leads to Prisma migrate wanting to DROP DEFAULT on that column, which is an error in pg.

Empty dbgenerated() were broken for all column types in v4 and fixed recently here: https://github.com/prisma/prisma/issues/14799. Seems like the fix didn’t apply to Unsupported() types.

How to reproduce

Clone & follow instructions here: https://github.com/jkcorrea/prisma-unsupported-dbgenerated-bug

Expected behavior

To not touch the defaults for any columns with default(dbgenerated()

Prisma information

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model table {
  id            String                   @id
  hereBeDragons Unsupported("tsvector")? @default(dbgenerated())
}

Environment & setup

• OS: macOS
• Database: Postgres
• Node.js version: v16.15.1

Prisma Version

Happens on prisma v4+ (including v4.4 and v4.5)

[janpio]

Indeed, removing the generated column and using a trigger instead might be the actually best solution right now. Be aware that the trigger is not reflected in Prisma schema, so you need to put it into a migration file manually once or it will be missing on new deployments.

[zakariamofaddel]

Thank you @janpio for the answer, I found this to be the cleanest solution at the moment:

• From the prod database I will remove the GENERATED ALWAYS AS (to_tsvector('english'::regconfig, <column-name>)) STORED from the columnName and leave it as a simple columnName tsvector.
• Always in prod I will then set a trigger, as @jkcorrea suggested, that will take care of setting the columnName to the correct type before every INSERT.
• Now running prisma db pull should generate columnName Unsupported("tsvector")? in my schema.prisma when running prisma db pull and always match the production database.

This should allow me to follow the prisma guide and cleanly introduce prisma migrate to the existing database.

I will update this comment if I’m successful 😄

EDIT: This was indeed the best solution I could find and it worked flawlessly. We were able to introduce prisma migrate to an existing database with lots of production data.

Thank you @jkcorrea!!