fix(docs): refer wrong raw query methods in ORM > Using Raw SQL > TypeSQL

[Hephaest]

Summary

In Dynamic SQL Queries with Dynamic Columns section, the doc clearly mentioned:

When you need to create a query where the columns are determined at runtime, you must use the $queryRaw and $executeRaw methods.
But in the example, it uses:

const columns = "name, email, age"; // Columns determined at runtime
const result = await prisma.$queryRawUnsafe(`SELECT ${columns} FROM Users WHERE active = true`);

It looks counterintuitive to me, so I do check on my own. The search results confirmed my assumptions: the doc might refer to the wrong methods.

Proofs:

Under $queryRaw considerations>

Under $executeRaw considerations>

Summary by CodeRabbit

• Documentation
  • Updated guidance for constructing SQL queries with dynamically determined columns.

[vercel]

@Hephaest is attempting to deploy a commit to the Prisma Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8effac45-3173-43a1-ab31-f5af9f49f611

📥 Commits

Reviewing files that changed from the base of the PR and between 8db1147 and 9f40946.

📒 Files selected for processing (2)

• apps/docs/content/docs.v6/orm/prisma-client/using-raw-sql/typedsql.mdx
• apps/docs/content/docs/orm/prisma-client/using-raw-sql/typedsql.mdx

---

Walkthrough

Two versions of Prisma TypedSQL documentation are updated to recommend $queryRawUnsafe and $executeRawUnsafe methods instead of $queryRaw and $executeRaw when dynamically constructing SQL queries with runtime-determined columns.

Changes

Documentation Guidance Update

Layer / File(s)	Summary
Documentation apps/docs/content/docs.v6/orm/prisma-client/using-raw-sql/typedsql.mdx, apps/docs/content/docs/orm/prisma-client/using-raw-sql/typedsql.mdx	Recommended methods for dynamic column selection updated from $queryRaw/$executeRaw to $queryRawUnsafe/$executeRawUnsafe in the "Dynamic SQL Queries with Dynamic Columns" limitation section. Both v6 and current doc versions aligned with this guidance.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: correcting documentation that was referring to the wrong raw query methods in the TypeSQL guide.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[aidankmcalister]

Good catch — the existing text is indeed wrong, and this fix is technically correct.

Why $queryRawUnsafe / $executeRawUnsafe is the right choice here:

$queryRaw and $executeRaw are implemented as tagged template literals. This design is intentional for SQL injection safety — Prisma converts interpolated values into parameterized query arguments. However, this mechanism only works for data values (e.g. WHERE email = ${email}). Template variables cannot be used for identifiers like column names, table names, or SQL keywords.

From our own docs on $queryRaw considerations:

"Variables cannot be used for identifiers such as column names, table names or database names, or for SQL keywords."

This means code like prisma.$queryRaw\SELECT ${columns} FROM Users`` would not work as intended for dynamic column selection — the column list would be parameterized as a bound value, not interpolated as SQL identifiers, causing a query error.

$queryRawUnsafe (and $executeRawUnsafe) accept a plain string and perform direct string interpolation, which is the only way to dynamically construct column/table identifiers at runtime. The example code in the docs is correct; only the preceding text was wrong.

The PR correctly updates the text in both v6 (content/docs/orm/v6/...) and v7 (content/docs/orm/...) docs to match the example.

Approved — thanks for the thorough investigation and the screenshots as proof!