migrate deploy on Postgres: schema_path problems

Bug description

I’m trying to use Prisma on top of Postgres/PostGIS to be able to use geo-related data types in my application. I know that PostGIS is not fully supported yet, but I nearly managed to get it working.

I try to create my tables in the backend schema, the PostGIS extension is installed in the public schema. I set the search_path on database level to public,backend. Now, if I run my migration SQL directly via a database client, everything works like a charm. When I try to run the migration via npx prisma migrate deploy, I see the following error:

Database error:
db error: ERROR: type "geometry" does not exist

It seems like prisma.js sets the wrong search_path upon connecting to the database. Unfortunately, I can’t seem to find the code portion which seemed to be there before (https://github.com/prisma/prisma/issues/5866#issuecomment-791233483).

How to reproduce

migration.sql

CREATE TABLE "geometries" (
    "geometry_id" SERIAL NOT NULL,
    "geometry" GEOMETRY
);

Expected behavior

The search_path for the respective DB user is used, instead of setting it (apparently) to the

Prisma information

model geometries {
  geometry_id Int     @unique @default(autoincrement())
  geometry    Unsupported("geometry")?
}

Environment & setup

• OS: MacOS Big Sur
• Database: Postgres 13.1 / PostGIS
• Node.js version: 14

.env

DATABASE_URL="postgresql://username:password@localhost:5432/mydatabase?schema=backend"

docker-compose.yml

version: '3.8'
services:
  postgis:
    image: "postgis/postgis:13-3.1"
    hostname: postgis
    container_name: postgis
    restart: always
    ports:
      - "5432:5432"
    volumes:
      - "./postgres-data:/var/lib/postgresql/data"
    environment:
      POSTGRES_USER: username
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydatabase
      PGDATA: /var/lib/postgresql/data/pgdata

Prisma Version

prisma               : 2.23.0
@prisma/client       : 2.23.0
Current platform     : darwin
Query Engine         : query-engine adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : adf5e8cba3daf12d456d911d72b6e9418681b28b
Studio               : 0.393.0

[tomhoule]

@tobilg sorry for the delay. The fix was merged and should be in the latest prisma@dev release — it would be awesome if you can confirm that it solves your problem.

[tobilg]

To sum it up: For our use case, being able to potentially define a search_path of more than one schema, while being able to define in which schema our model needs to deployed would solve our problems.

Thanks for all the insights!