This may be sufficient depending on the usecase, but from what I can tell from docs, its not exactly what OP is asking for. @default uses Postgres' DEFAULT, which is not the same as Postgres' GENERATED ALWAYS AS [...] STORED, in at least two ways:

1. With the latter, the DB keeps the generated column's value in sync on UPDATEs
2. With the latter, the DB disallows writes (by clients) to the column

Correct. DEFAULT doesn't help this specific use case.

Besides the limitations mentioned above, the workaround does not work in Postgres, because default values cannot reference other columns.
Quote from the create table docs:

The value is any variable-free expression (in particular, cross-references to other columns in the current table are not allowed).

Sad! I want Prisma to either support Postgres GENERATED or ignore this column entirely (also not clear it, or drop the DEFAULT like it does now when I mark it as either @ignore or Unsupported)

I'd like to contribute this if needed, but I have no idea if this aligns with the current backlog, priorities, vision and manifesto.

Hi, thanks for the suggestion. I tried this workaround, but it didn’t work because Prisma doesn’t allow adding a column that already exists.

Even if I drop the column beforehand, the approach still seems to fail, since running prisma migrate dev makes Prisma attempt to drop the column that was just created manually.

Could you please provide a more detailed step-by-step explanation of how this method is supposed to work?

the way I solve problems for feature prisma doesn't support is so when creating migrations:

1. Backup your local database
2. Run prisma migrate dev to generate migrations
3. Remove unwanted changes and sql code from the generated migration file, and make manual changes to what you need/want.
4. Restore your local databse before the migration
5. Reapply the migrations using prisma migrate deploy

For production environments this is not an issue, because you just run migrate deploy, it runs the sql commands, doesn't check any of them or if schema matches, so prisma is tricked and we are happy. But we're running into more and more issues prisma doesn't support and we're very close to ditching it entirely.

Today i wanted to add a "complex" gis function to my prisma schema via generated so I added it:

model Location {
...
  locationData? Json @map("location_data")
  locationBoundaryBox     Unsupported("gis.box2d")?    @default(dbgenerated("\nCASE\n  WHEN ((location_data is null) OR (location_data -> 'bbox' is null))\n THEN NULL::gis.box2d\n ELSE \n gis.box2d(gis.st_makeenvelope ((location_data -> 'bbox' ->> 0)::double precision, (location_data -> 'bbox' ->> 1)::double precision, (location_data -> 'bbox' ->> 2)::double precision, (location_data -> 'bbox' ->> 3)::double precision, 4326))\nEND")) @map("location_boundary_box")
 ...
}

When you run a normal prisma migrate dev it will fail, because the generated code uses DEFAULT instead of generated. I fixed it like this without backup of database:

1. add the line to the schema.
2. Run prisma migrate dev --create-only
3. change it to the sql you require

-- AlterTable
ALTER TABLE "public"."locations"
  ADD COLUMN "location_boundary_box" gis.box2d GENERATED ALWAYS AS ( CASE WHEN ((location_data IS NULL)
    OR (location_data -> 'bbox' IS NULL)) THEN
    NULL::gis.box2d
  ELSE
    gis.box2d(gis.st_makeenvelope((location_data -> 'bbox' ->> 0)::double precision,(location_data -> 'bbox' ->> 1)::double precision,(location_data -> 'bbox' ->> 2)::double precision,(location_data -> 'bbox' ->> 3)::double precision, 4326))
  END) STORED;

4. run prisma migrate dev --create-only It will apply your migration and then ask to create a new migration which will contain the same messed up SQL Migration as before.

5. Instead of providing a name on "Enter a name for new migration: " CMD + C to Abort.

6. Now make a git commit so that your workspace is clean.

7. Run prisma db pull for me this messes up a lot of things in my prisma file, BUT I am only interested in the line which I had trouble with:

 locationBoundaryBox     Unsupported("box2d")?        @default(dbgenerated("\nCASE\n    WHEN ((location_data IS NULL) OR ((location_data -> 'bbox'::text) IS NULL)) THEN NULL::gis.box2d\n    ELSE gis.box2d(gis.st_makeenvelope((((location_data -> 'bbox'::text) ->> 0))::double precision, (((location_data -> 'bbox'::text) ->> 1))::double precision, (((location_data -> 'bbox'::text) ->> 2))::double precision, (((location_data -> 'bbox'::text) ->> 3))::double precision, 4326))\nEND")) @map("location_boundary_box")

8. Copy the line

9. Reset the local changes in git reset --hard.

10. Overwrite your existing line in the prisma schema with the line you copied from the prisma db pull version.

For me he changed a little bit the spacing nothing more.

model Location {
  ...
  locationData            Json?                        @map("location_data")
  locationBoundaryBox     Unsupported("box2d")?        @default(dbgenerated("\nCASE\n    WHEN ((location_data IS NULL) OR ((location_data -> 'bbox'::text) IS NULL)) THEN NULL::gis.box2d\n    ELSE gis.box2d(gis.st_makeenvelope((((location_data -> 'bbox'::text) ->> 0))::double precision, (((location_data -> 'bbox'::text) ->> 1))::double precision, (((location_data -> 'bbox'::text) ->> 2))::double precision, (((location_data -> 'bbox'::text) ->> 3))::double precision, 4326))\nEND")) @map("location_boundary_box")
}

11. Run prisma migrate dev --create-only the resulting migration file should be empty meaning that your schema.prisma is now in sync with what prisma sees in the database.

I hope that helps.