Type error in `IN` clause in postgreSQL using `$queryRaw` when upgrading to v4

Bug description

There seems to be a regression regarding IN clauses in postgreSQL in prisma v4.

The issue happened on postgresql and the behaviour changed somewhere between prisma 3.15.2 and 4.2.1.

For a given table of this structure:

CREATE TABLE repro(
    `id` UUID NOT NULL PRIMARY KEY,
)

When querying a list of rows using an IN query clause like so:

   const rows = await this.prismaClient.$queryRaw<
    { id: string }[]
    >(Prisma.sql`
      SELECT id
      FROM repro
      WHERE id IN (${Prisma.join(ids)});
    `)

This worked fine in 3.15.2 but returns a type error in 4.2.1:

{
  "code": "P2010",
  "clientVersion": "4.2.1",
  "meta": {
    "code": "42883",
    "message": "db error: ERROR: operator does not exist: uuid = text\nHINT: No operator matches the given name and argument types. You might need to add explicit type casts."
  }
}

I’ve tried different castings but nothing seemed to work.

This query works on the other hand:

   const rows = await this.prismaClient.$queryRaw<
    { id: string }[]
    >(Prisma.sql`
      SELECT id
      FROM repro
      WHERE id = ANY (ARRAY[${Prisma.join(ids)}]::uuid[]);
    `)

I haven’t seen what would cause this in the upgrade guide and it does look like a regression to me. I’m guessing there’s a change in how the casting is done which broke this query.

How to reproduce

A reproduction repository is available here: https://github.com/floriantz/repro-prisma

Expected behavior

The query should not cause an error

Prisma information

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

datasource db {
  provider = "postgres"
  url      = "postgres://postgres:postgres@localhost:5432/postgres"
}

model repro {
  id String @id @db.Uuid
}

Environment & setup

• OS: MacOS 12.2.1
• Database: PostgreSQL
• Node.js version: 16+

Prisma Version

prisma                  : 4.2.1
@prisma/client          : 4.2.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : 2920a97877e12e055c1333079b8d19cee7f33826
Studio                  : 0.469.0

[Weakky]

Hey @floriantz,

Could you try casting every single uuids as follow?

const ids = [
 '422b72f9-2ec9-4482-8a2f-527251af5606',
 'ee5f92a7-1741-48d4-b8c3-517e9621453a',
].map(uuid => Prisma.sql`${uuid}::uuid`);

const rows = await client.$queryRaw`
  SELECT id
  FROM repro
  WHERE id IN (${Prisma.join(ids)});
`;

Let us know whether that fixes your issue.

[floriantz]

I had tried something similar, yet a bit different. It works indeed with my repro case ✅ . Though it would be super helpful to update Prisma.join() to accept a type casting argument as proposed by @emmanuelpineda.

I understand your choice of explicit types (actually I’m quite in favour of it), but the UX suffers a bit at the moment imho.