@prisma/orm-postgres 8.0.0-rc.17-dev.18 → 8.0.0-rc.17-dev.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prisma/orm-postgres",
-  "version": "8.0.0-rc.17-dev.18",
+  "version": "8.0.0-rc.17-dev.20",
   "license": "Apache-2.0",
   "type": "module",
   "sideEffects": false,
@@ -10,10 +10,10 @@
     "skills"
   ],
   "dependencies": {
-    "@prisma/orm-family-sql": "8.0.0-rc.17-dev.18",
-    "@prisma/orm-framework": "8.0.0-rc.17-dev.18",
-    "@prisma/orm-target-postgres": "8.0.0-rc.17-dev.18",
-    "@prisma/orm-toolchain": "8.0.0-rc.17-dev.18",
+    "@prisma/orm-family-sql": "8.0.0-rc.17-dev.20",
+    "@prisma/orm-framework": "8.0.0-rc.17-dev.20",
+    "@prisma/orm-target-postgres": "8.0.0-rc.17-dev.20",
+    "@prisma/orm-toolchain": "8.0.0-rc.17-dev.20",
     "@types/node": "26.1.2",
     "@types/pg": "8.20.4",
     "arktype": "^2.2.2",
@@ -22,9 +22,9 @@
     "tinyglobby": "^0.2.17"
   },
   "devDependencies": {
-    "@internal/postgres": "8.0.0-rc.17-dev.18",
-    "@repo/tsconfig": "8.0.0-rc.17-dev.18",
-    "@repo/tsdown": "8.0.0-rc.17-dev.18",
+    "@internal/postgres": "8.0.0-rc.17-dev.20",
+    "@repo/tsconfig": "8.0.0-rc.17-dev.20",
+    "@repo/tsdown": "8.0.0-rc.17-dev.20",
     "tsdown": "0.22.14",
     "typescript": "5.9.3"
   },

package/skills/prisma-8/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   ORM 7 or earlier (schema.prisma + @prisma/client).
 metadata:
   library: '@prisma/orm-postgres'
-  library_version: '8.0.0-rc.17-dev.18'
+  library_version: '8.0.0-rc.17-dev.20'
   version: '2026-09-12'
 ---
 

package/skills/prisma-8/references/migrations.md

@@ -52,7 +52,7 @@ Once the contract changes, you choose how the change reaches the database. This
 
 Files under `migrations/<space-id>/<timestamp>/migration.ts` (for your own app, `<space-id>` is always `app/`) are **rendered for you** by the framework — `prisma migration plan` writes a populated package whenever the contract changes, and `prisma migration new` writes an empty scaffold when you want to author operations directly. You do not write these files from scratch. You edit specific holes the framework leaves behind — chiefly replacing `placeholder("<slot>")` sentinels (Postgres) or filling `dataTransform({ check, run })` pipeline slots (Mongo) — then self-emit.
 
-**Postgres** rendered imports point at `@internal/postgres/migration` (or `@internal/sqlite/migration` for SQLite projects): one line carrying `Migration`, `MigrationCLI`, `col`, `placeholder`, `rawSql`, and any other free helper the operations need.
+**Postgres** rendered imports point at `@internal/postgres/migration` (or `@internal/sqlite/migration` for SQLite projects): one line carrying `Migration`, `MigrationCLI`, `col`, `placeholder`, `rawSql`, `sql` when the file writes a `sql` value, and any other free helper the operations need.
 
 **Mongo** rendered imports point at one module too, `@prisma/orm-mongo/target/migration`, which carries `Migration`, `MigrationCLI`, `placeholder`, and the operation factories (`createIndex`, `dataTransform`, …). Raw command classes for data transforms come from `@prisma/orm-mongo/query-ast/execution`.
 
@@ -364,7 +364,7 @@ On Postgres the operations are **methods on the `Migration` base class**, each t
 **Postgres** operations (representative set, all `this.<name>({...})`):
 
 - Tables: `createTable`, `renameTable`, `dropTable`. `renameTable` reads the migration's start and end contracts and returns the table rename plus a rename of every constraint and index named after the old table, so spread it: `...this.renameTable({ table: 'userProfile', to: 'UserProfile' })`.
-- Columns: `addColumn` (`column: col(name, nativeType, { codecRef })`), `renameColumn` (also renames the constraints and indexes named after the column, so spread it: `...this.renameColumn({ table: 'User', column: 'email', to: 'emailAddress' })`), `dropColumn`, `alterColumnType` (pass `operationClass: 'widening'` only when every value of the old type converts to the new type unchanged, such as `int4` to `int8`; the default is `'destructive'`), `setNotNull`, `dropNotNull`, `setDefault` (`column: col(name, nativeType, { default: lit(value) or fn(expression), codecRef })`; `fn('autoincrement()')` on a smallint, integer or bigint column creates or reuses the `{table}_{column}_seq` sequence, attaches it, and starts it past the column's largest value), `dropDefault`.
+- Columns: `addColumn` (`column: col(name, nativeType, { codecRef })`), `renameColumn` (also renames the constraints and indexes named after the column, so spread it: `...this.renameColumn({ table: 'User', column: 'email', to: 'emailAddress' })`), `dropColumn`, `alterColumnType` (pass `operationClass: 'widening'` only when every value of the old type converts to the new type unchanged, such as `int4` to `int8`; the default is `'destructive'`), `setNotNull`, `dropNotNull`, `setDefault` (`column: col(name, nativeType, { default: lit(value) or fn(…), codecRef })`, where `fn` takes a SQL expression; `fn`, `checkExpression` and the methods that take a SQL fragment accept a ``sql`...` `` value, which generated files write, or a string; a `sql` value's text is canonicalized like a contract's, a string is kept exactly as written, so do not wrap a committed string in `sql`; `fn('autoincrement()')` on a smallint, integer or bigint column creates or reuses the `{table}_{column}_seq` sequence, attaches it, and starts it past the column's largest value), `dropDefault`.
 - Constraints: `addPrimaryKey`, `addForeignKey`, `addUnique`, `addCheckConstraint`, `renameConstraint` (`kind`: `primaryKey`, `unique`, `foreignKey` or `checkConstraint`), `renameCheckConstraint`, `dropCheckConstraint`, `dropConstraint`.
 - Indexes: `createIndex`, `renameIndex`, `dropIndex`.
 - Enums: `createNativeEnumType`, `addNativeEnumValue`, `dropNativeEnumType`.