Change SQL placeholders without losing argument order

Tools to use

• Open this tool: SQL placeholder converter

Start with two values

SELECT * FROM orders WHERE owner = :user AND state = :state;

{"user":"demo","state":"open"}

Select named input and postgresql output and supply the JSON object. SQL occurrence order makes :user $1 and :state $2; JSON key order does not determine these numbers. Inspect arguments as well as sql: $1 must map to demo and $2 to open.

The target selects numbered placeholder syntax, not a complete SQL dialect migration. Date functions, types and identifier rules are not automatically translated. Limit the review to parameter markers and mappings, then check dialect differences separately.

Does a repeated name need another value?

SELECT * FROM tasks WHERE owner = :user OR reviewer = :user;

With {"user":"demo"}, numbered output uses $1 twice to preserve identity. Question-mark output instead has two positional arguments, demo and demo. Identical-looking question marks still represent separate occurrences.

parameters records each SQL occurrence; arguments describes values for the target. Distinguish occurrence count from distinct identities. Also verify that reusing the name was intentional: conversion cannot repair a mistaken reuse.

Leave literals and comments alone

SELECT ':user' AS note FROM tasks WHERE owner = :user; -- :user

Only the WHERE marker changes. The quoted string is data and the final marker is in a comment. A blind replacement would alter both. Review unchanged text as well as changed markers.

This is not a parser for every SQL extension. Vendor-specific quoting, operators and casts need separate review. PostgreSQL question marks can be operators, so question-source conversion with that dialect is rejected. Do not change dialect merely to silence the error.

Check extra arguments as well as missing ones

If SQL uses only :user but arguments still contain state, stale query configuration may remain. Missing and extra named keys are errors. Positional input takes a JSON array checked against required positions. Find the stale side rather than inserting empty values to make validation pass.

Finish by checking the driver contract

Successful conversion does not establish that a driver accepts the target syntax. Check its documented SQL-and-arguments interface and test expected rows in an isolated dataset. Keep parameter binding rather than concatenating values into SQL, and use fictional values instead of secrets.

Sources

• SQLite — SQL expressions and parameters (Opens in a new tab)

Tools to use

• SQL placeholder converter